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Description 

Field of the Invention 

[0001] This invention relates generally to mobile com- 
munications, and in particular to pushing Information to 
mobile communication devices. 

Description of ttie State of the Art 

[0002] Known solutions for providing information to 
mobile communication devices tend to be relatively lim- 
ited. For example, Wireless Application Protocol (WAP) 
browsers for mobile devices typically provide access only 
to Information associated with WAP-compliant sources 
and when such information is requested by a user. Al- 
though other known and similar products may allow a 
mobile device user to access further information sources, 
such products generally do not make efficient use of mo- 
bile communication network resources, particularly wire- 
less communication links, since some sort of information 
request must generally be made before every transfer of 
information. 

[0003] Furthermore, most known data access systems 
and methods are not suited to provide truly secure access 
to confidential information stored on private networks, 
such as corporate information located on data store be- 
hind a security firewall. 

[0004] Therefore, there remains a need for a system 
and method for pushing information from an Information 
source to a mobile communication device. 
[0005] EP 0 992 922 A2 discloses automatic image 
data quality adjustment to reduce response time of a web 
server. Transcording parameters of images of retrieved 
web documents are dynamically adjusted In a transcod- 
ing proxy. The adapted transcoder chooses different pa- 
rameters for each object and provides performance im- 
provements. The proposed system compresses only im- 
ages of HTTP server responses to conresponding re- 
quests from a client. 

[0006] US 6 21 6 1 57 B1 discloses method and appa- 
ratus to deliver information content from a push applica- 
tion to a client through a transmission medium. An appli- 
ance specific transducer and an adapted transmission 
transducer are added to the push application for com- 
pressing information such as image, audio, or video. 
[0007] Mogul, J.D., "Server-directed transcoding", 
Computer Communications 24 (2001 ), pages 1 55 to 1 62. 
proposes a transcoding proxy for transcoding image data 
retrieved with responses to HTTP requests. Server-di- 
rected transcoding applets use explicit guidance from the 
web server to allow the transcoding proxy to make the 
best possible choice for transcoding of the retrieved web 
pages. 

SUMMARY 

[0008] The instant application describes a system and 



method for pushing information source to mobile com- 
munication devices according to the independent claims. 
[0009] The systems and methods described herein 
provide for pushing of any of a plurality of types and for- 
5 mats of Information to mobile communication devices. 
Particular information translation operations may be se- 
lected by a mobile communication device, an infomiation 
source or an intermediate data server system and per- 
formed on an information source side of a mobile com- 
munication system. This not only reduces the complexity 
of device processing operations and any device hard- 
ware and software components associated with such op- 
erations, but also provides for customized device Infor- 
mation formats. 
IS [0010] The system for pushing information content 
from an information source to a mobile communication 
device over a network includes a transcoding system and 
a first network device. The transcoding system Includes 
a plurality of transcoders, each transcoder operable to 
20 transcode the infomiation content from a respective input 
content type into a respective output content type. The 
first network device is in communication with the trans- 
coding system, and includes a push module. The push 
module is operable to receive a connection request from 
25 the Infomiation source. The connection request includes 
an identifier associated with the mobile communication 
device. The push module is further operable to select a 
corresponding connection handler that is operable to se- 
lect one or more transcoders from the plurality of trans- 
30 coders to transcode the information content based on 
the identifier associated with the mobile communication 
device. 



BRIEF DESCRIPTION OF THE DRAWINGS 

35 

[0011] 

Fig. lis a general block diagram of a communication 
system that provides for pushing data from an infor- 
^0 matton source to a mobile communication device. 
Fig. 2 is a more detailed block diagram of the system 
shown in Fig. 1 . 

Fig. 3 is a flow chart representing general connection 
handler-related operations in an IP system. 
<5 Fig. 4 is a flow chart of connection handler data 

processing operations. 

Fig. 5 is a signal flow diagram of an example infor- 
mation push operation. 

Fig. 6 is a signal flow diagram showing multiple or 
50 "chained" transcoding operations for an HTTP- 
based push operation. 

Fig. 7 is a signal flow diagram of an example of push 
server-controlled transcoder selection for an HTTP- 
based push operation. 
55 Fig. 8 is a general block diagram of a communication 
system with an external transcoder system. 
Fig. 9 is a signal flow diagram Illustrating an HTTP- 
based push operation with an external transcoder 
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system such as shown in Fig. 8. 
Fig. 10 shows a further signal flow diagram for an 
external transcoder system. 
Fig, 1 1 is a biocl< diagram showing an IP Proxy sys- 
tem implemented in a secure network. 
Fig. 12 is a signal flow diagram illustrating a corpo- 
rate data push operation. 

DETAILED DESCRIPTION 

General System Description 

[0012] Fig. 1 is a general block diagram of a commu- 
nication system that provides for pushing of information 
from a remote information source 20 to a wireless mobile 
communication device 12. 

[001 3] The following description of the communication 
system facilitates the understanding of the present in- 
vention. 

[0014] In Fig. 1 , the system 10 includes the mobile de- 
vice 12, a wireless network 14, a wireless network gate- 
way 1 5. a wide area network (WAN) 1 6, an Internet Pro- 
tocol (IP) Proxy system 18, and an information source 
20. Although an IP Proxy system 18 is shown in the il- 
lustrative example system of Fig. 1, proxy systems for 
protocols other than IP may be implemented, too. Proto- 
cols at other levels within the Open Systems Intercon- 
nection(OSI) model can also be proxied using this sys- 
tem. Such other protocols include but are not limited to 
HTTP and TCP. 

[001 5] The mobile device 1 2 may be any mobile com- 
munication device adapted to operate within a wireless 
communication network 14, and is preferably a two-way 
communication device. The mobile device 12 may also 
have voice and data communication capabilities. De- 
pending on the functionality provided by the mobile de- 
vice 12, the mobile device 12 may be referred to as a 
data messaging device, a twoway pager, a cellular tele- 
phone with data messaging capabilities, a wireless Inter- 
net appliance or a data communication device (with or 
without telephony capabilities), but is referred to herein 
primarily asa"mobile device". As will be apparent to those 
skilled in the field of communications, the particular de- 
sign of a communication subsystem within the mobile 
device 12 will be dependent upon the communication 
network 14 in which the mobile device 12 is Intended to 
operate. For example, a mobile device 1 2 destined for a 
North American market may include a communication 
subsystem designed to operate within the Mobitex mobile 
communication system or Data TACTM mobile commu- 
nication system, whereas a mobile device 12 intended 
for use in Europe may incorporate a General Packet Ra- 
dio Service (GPRS) communication subsystem. Those 
skilled in the art will also appreciate that other types of 
mobile devices and networks are also contemplated. The 
inventive systems and methods described herein may 
be implemented in conjunction with virtually any wireless 
network 14. 



[0016] The gateway 15 shown in Fig. 1 provides an 
interface between the wireless network 14 and a WAN 

16, which may, for example, be the Intemet. Such func- 
tions as mobile device addressing, conversion of data 
5 between WAN protocols and wireless network protocols, 
storing and fonwarding data to and from the mobile device 
12, and other interface functions may be performed by 
the gateway 1 5. 

[0017] It is also possible that an IP Proxy system 18 
could be hosted by a network carrier/operator associated 

with the wireless network 14. In this case, the connection 
between the IP Proxy system 18 and the gateway 15 
would use a private network of the carrier instead of the 
WAN 16. The WAN 16 could then be used to communi- 
cate between the IP Proxy system 1 8 and the information 
source 20. 

[0018] The IP Proxy system 18 is a system that effec- 
tively provides the information source 20 with access to 
the mobile device 12, and is described in further detail 
below. Through the IP Proxy system 18, any information 
source 20, such as an Internet or web server, that can 
communicate with the IP Proxy system 1 8 may push in- 
formation to a mobile device 12. The information source 
20 therefore requires no special applications or protocol 
support for wireless network communications, since It 
communicates with the IP Proxy system 18 and not di- 
rectly with the mobile device 12. Although shown in Fig. 
1 as a direct connection, the IP Proxy system 18 and 
information source 20 may possibly communicate 
through a network such as a local area network (LAN) or 
WAN, including the Internet. 

[001 9] Wireless networks and the Internet use similar 
addressing schemes, in which recipients, such as mobile 
devices in a wireless network or Internet-connected com- 
puters, are identified by numerical addresses. For exam- 
ple, mobile devices are identified in the Mobitex network 
using a Mobitex Access Number (MAN), and public In- 
ternet nodes are identified using an IP address scheme. 
However, differences between wireless network and In- 
temet transport mechanisms prevent direct communica- 
tion between information sources 20, the vast majority 
of which are Internet-based, and mobile devices such as 
12. Furthermore, information source content is largely 
targeted to desktop or other computer systems with rel- 
atively powerful processors and may require that proc- 
essor-intensive operations such as information parsing 
be performed by a recipient. Since mobile devices tend 
to have less powerful processors, these operations take 
more time on such mobile devices than on computer sys- 
tems and can consume significant amounts of power 
from normally limited-power sources. The IP Proxy sys- 
tem 18 bridges the gap between Internet-based and pos- 
sibly other information sources 20 and a wireless network 
14 with associated mobile devices 12. These services 
may include address mapping, content transformation 
and verification, and protocol mapping and optimisation, 
for example. 
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Detailed Description of the IP Proxy Syste m 

[0020] Fig. 2 is a more detailed blocl^ diagram of the 
IP Proxy system 1 8 shown in Fig. 1 . The IP Proxy system 
18 may include a dispatcher 22, a Transmission Control 
Protocol (TCP) handler 24, a Hypertext Transfer Protocol 
(HTTP) handler 26. a transcoding system 28, one or more 
push services generally designated 30, a state persist- 
ence element 34, a monitoring system 36, and a logging 
system 38. Fig. 2 also shows a push server 42, a web 
server 46, a web browser 48, and a file system 40, with 
which the IP Proxy system 18 may interact from time to 
time. Many of the components shown in Fig. 2 may be 
implemented primarily as computer software modules. 
Elements within the IP Proxy system 18 will typically be 
running on the same computer, whereas components 
external to the IP Proxy system 18 are normally resident 
on separate computers. In an alternative implementation, 
the elements of an IP Proxy system 18 may instead be 
distributed among a group of computers distributed over 
a network. 

[0021] Dispatcher 22 manages data flows and the con- 
nection to the gateway 1 5. Depending on the type of con- 
nection or the type of data being transferred or data trans- 
action being performed for example, the dispatcher 22 
interacts with the TCP handler 24 or the HTTP handler 
26. The transcoding system 28 comprises one or more 
data filters, each of which converts data or other infor- 
mation from one format into a format that can be proc- 
essed by a mobile device 12. 

[0022] Push services 30 provide for pushing to a mo- 
bile device, or transfer of "unsolicited" information from 
an information source such as push server 42, which may 
for example be a web server or a software application, 
to a mobile device 12 through the IP Proxy system 18. 
The push services component 30 allows the push server 
42 to address the mobile device using for example the 
email address of the mobile device owner or some other 
convenient label. Accordingly, the push server 42 need 
not know the address of the mobile device 1 2 in the wire- 
less network 14. 

[0023] The state persistence element 34, in conjunc- 
tion with a data file system 40 or a database, enables 
management of cookies, passwords and possibly other 
state information associated with web servers 46 to which 
the IP Proxy system 18 may connect. It preferably stores 
state information about a connection that persists be- 
tween discrete network packets, such as an HTTP re- 
quest/response pair. 

[0024] The monitoring system 36 allows remote mon- 
itoring of the performance, efficiency, usage and health 
of an IP Proxy system 18 by an administrator. This mon- 
itoring may be accomplished for example through a local 
interface with the IPProxy system 18 or possibly remotely 
through an interface such as a web browser 48. As its 
name implies, the logging system 38 may be configured 
to store usage, connection, user statistics and the like to 
the file system 40 or some other secondary storage. 



Connections and Handlers 

[0025] The IP Proxy system 18 can preferably handle 
and process content from various information sources 

5 20. including Internet-based sources. This functionality 
is provided by connection handlers, which are interme- 
diate objects that have the ability to process content from 
inbound and outbound connections to an IP Proxy sys- 
tem 18. In the IP Proxy system 18 shown in Fig. 2, two 

10 such handlers, the TCP handler 24 and the HTTP handler 
26, are shown. These handlers can preferably be re- 
placed and customized or additional handlers can pref- 
erably be added to an IP Proxy system as needed. The 
connection handlers can optimise not just the content but 

IS also the protocol. For example, some requests that would 
normally be sent to the mobile device 12 (such as a re- 
quest for a password) may be resolved by the connection 
handier, where required information Is available through 
the state persistence element 34 and the file system 40, 

20 for example. This instance of a protocol optimisation can 
adapt so-called "chatty" protocols to be more wireless 
friendly by reducing the amount of traffic sent over a wire- 
less network to a mobile device 12, thereby reducing the 
effects of wireless network bandwidth constraints and 

25 latency. 

[0026] Outbound connections would be made from 
mobile devices 12 in order to send data to and receive 
data from Internet nodes for example. The IP Proxy sys- 
tem 1 8 preferably receives connection requests from mo- 

30 bile devices 1 2 using a particular protocol, such as a pro- 
prietary protocol called IP Proxy Protocol or IPPP devel- 
oped by the assignee of the present application, although 
other protocols might also be used. The IP Proxy system 
18 then establishes an Internet connection, according to 

35 routing information provided by the mobile device 12, and 
translates and maps that connection to start fonA^arding 
data in both directions. A filtration or transcoding process 
is invoked whenever necessary, based for example on 
the type of content being passed over the connection, or 

^0 on a particular transcoding process specified in the con- 
nection request from the mobile device. 
[0027] Inbound connections are used, for example, to 
implement a data push model in accordance with one 
embodiment. In this embodiment, a mobile device 12 

45 may be sent information without having issued requests 
to fetch the information, as is the case with outbound 
connections. As described briefly above, mobile devices 
12 may exist on a different network domain than internet 
nodes. The IP Proxy system 1 8 Is responsible for bridging 

50 the Internet and wireless network domains. Thus, the IP 
Proxy system 18 requires certain routing information to 
route the traffic to a particular mobile device 12. In a push 
operation, at least some of this routing infonnation must 
be provided by the internet node, such as the push server 

55 42, that issues the request to establish an inbound con- 
nection. The IP Proxy system 18 may convert commonly 
known addressing schemes such as email or IP numbers 
into the appropriate wireless network address of an in- 
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tended recipient mobile device 1 2. A transcoding process 
for pushed content may also be selected and specified 
by a push server 42 or information source 20. 
[0028] Connection handlers in an IP Proxy system 18 
are stream-based objects. When an outbound or Inbound 
connection is requested, a virtual piped stream is estab- 
lished between a mobile device 12 and the appropriate 
connection handler. The connection handler will be in- 
stantiated and started to process the content for the es- 
tablished connection. Loading the connection handler is 
based on a connection request, which preferably con- 
tains a reference to appropriate handler name that nor- 
mally implies the type of the traffic that would go through 
the virtual piped stream and the location of the handler 
that must be loaded if It is not already loaded. The func- 
tions of connection handlers include mapping Internet or 
other information source-side connections and mobile 
device 12 connections, forwarding traffic between these 
connections, and loading and invoking the appropriate 
transcoders on information destined for a mobile device 
12. 

[0029] Every connection is preferably associated with 
an Instance of a connection handler. This is true even for 
a connection that does not require that content be proc- 
essed by the IP Proxy system 18, such as a pure TCP 
connection between a mobile device and a server. This 
type of connection handler forwards content back and 
forward without making any sort of modification to the 
content, although it may make modifications to the pro- 
tocol. For clarity, those skilled in the art will appreciate 
the distinction between the data or content (what the mo- 
bile device requested or is being sent) and the protocol 
(the "wrappers'* and conversions required to deliver the 
data). 

[0030] Connection handlers are also responsible for 
loading the appropriate content filters or transcoders. A 
connection handler such as the HTTP connection han- 
dler 26 may use a particular transcoder in the transcoder 
system 28 selected by the IP Proxy system 18 or spec- 
ified by either the mobile device 12 or an Information 
source such as push server 42 or web server 46. 
[0031] Fig. 3 is a flow chart representing general con- 
nection handler-related operations in an IP Proxy system 
18. At step 50, the IP Proxy system 18 receives a con- 
nection request, which as described above may relate to 
an inbound connection oran outbound connection. When 
the connection is associated with a particular handler, 
such as an HTTP connection that requires HTTP con- 
nection handler 26, the appropriate handler Is loaded and 
executed at step 54 and the connection is established, 
as indicated at step 58. If the request Is outbound (from 
the mobile device 12), then the dispatcher 22 examines 
the protocol type associated with the request and dele- 
gates the connection to the appropriate handler. Data 
may then be exchanged between a mobile device and 
an Internet service, push server 42, web server 46 or 
other information source 20. 

[0032] If certain connection handlers are used for a 



connection, such as for a pure TCP connection as de- 
scribed above, then the data may pass through the IP 
Proxy system 18 unchanged. In some IP Proxy systems 
however, content sent over a TCP handler may be mod- 

5 ified. When other connection handlers are used however, 
data destined for a mobile device 12 may need to con- 
verted into a suitable format. Fig. 4 is a flow chart of con- 
nection handler data processing operations. At step 62, 
data destined for a mobile device 1 2 is received. Although 

10 labelled as a response from a connection, following an 
Information request from a mobile device 12 for example, 
it should be understood that data received by the con- 
nection handler may instead be information to be pushed 
to the mobile device 12 from a push server such 42 via 

IS a push service 30. The connection handler determines 
at step 64 If transcoding is required. If not, then the in- 
formation is sent to the mobile device 12 at step 70. 0th- 
enwise, the appropriate transcoder is loaded and execut- 
ed in step 66. The data is transcoded into an acceptable 

20 format ion step 68 before being sent to the mobile device 
1 2 at step 70. The entity that initiates the communication, 
the mobile device 12 for fetched data or the push server 
42 for pushed data, can preferably specify a particular 
transcoder to do the transcoding of the fetched or pushed 

25 data. Transcoder selection may also be made by a con- 
nection handler or IP Proxy system 1 8 dependent on des- 
tination mobile device 12 information available to the IP 
Proxy system 18 or possibly inferable by an IP Proxy 
system 18 or components thereof based on previous in- 

30 fomiation transfer operations Involving the destination 
mobile device 12. For example, a transcoder may be in- 
voked to transcode information into the same format that 
was previously transferred to a destination mobile device 
1 2 the last time information was sent to the mobile device 

35 12. 

[0033] A connection handler may be implemented in 
computer software as a Java™ class file, placed in a cer- 
tain directory in a file system such that an IP Proxy system 
Java Virtual Machine (VM) may locate and load the file 

^0 when needed or requested. As those skilled in the art will 
appreciate, Java uses CLASSPATH environment varia- 
ble as a guide to where it should perform a lookup for 
user defined classes. In one embodiment, paths to con- 
nection handlers are to be among the first listed paths in 

45 the CLASSPATH so that they would be loaded relatively 
quickly when requested. The connection direction (in- 
bound or outbound) and the name associated with a con- 
nection handler may also play a role in defining the full 
class name of a handler. Those skilled in the art will ap- 

50 predate that the same schemes could be implemented 
using dynamic linked libraries (DLLs) or dynamic shared 
objects (DSOs) depending on the target operating sys- 
tem. 

[0034] Connection handlers can be associated with a 
55 name that represents a protocol at the application layer. 
For example, if a mobile device 1 2 is enabled with a web 
browser and may therefore request to open connection 
to an Internet server such as 46, it would be appropriate 
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to have HTTP as a name for that connection handler, as 
shown with connection handler 26. The handler name 
may adhere to the known rules of naming packages in 
Java language. Preferably, the handler name is in lower 
case; however, from an IP Proxy system point of view, it 
does not matter as long as the Java VM can load that 
connection handler. Any Connection Handler may also 
have its class name as Handler.class. An example of a 
valid full class name that represents a connection handler 
is as follows: 

net.rim.protocol.iplayer.connection.handler.<connec- 
tion direction>.<connection handler name>. Han- 
dler.class 

where connection direction can be either device, which 
implies outbound connection, or server, which implies 
inbound connection. Connection handler name is the 
name associated with the handler, for instance, http, ftp, 
etc. 

[0035] There are at least two ways that an information 
source such as an internet node can establish a connec- 
tion to a mobile device 12 through the example IP Proxy 
system 18 shown in Fig. 2: (1) using a transportation 
layer protocol directly, such as TCP, to open a direct con- 
nection to the IP Proxy system 18, or (2) using adatagram 
protocol at the application layer, such as HTTP. The IP 
Proxy system 1 8 includes two corresponding connection 
handlers, which may, for example, represent a basic IP 
Proxy system 1 8 which can process two of the most com- 
mon types of connection. The first is the TCP connection 
handler 24, associated for example with the name top. 
The second is the HTTP connection handler 26, which 
may similarly be associated with the name http, as de- 
scribed above. In addition to supporting common con- 
nection types, these connection handlers also satisfy re- 
quirements for Mobile Information Device Profile (MIDP) 
implementation at the mobile device. However, the IP 
Proxy system 18 and the mobile device 12 can be ex- 
tended to support any other types of connections. In thefP 
Proxy system 18, connection handlers may possibly be 
added by providing an application programming interface 
(API) in thelP Proxy system 1 8 and developing new con- 
nection handlers that adhere to the API, for example. 
[0036] In one example, connection handlers in the IP 
Proxy 18 are loaded from a local storage medium, for 
example a disk drive associated with a computer on 
which IP Proxy system software is running. However, in 
another example, connection handler storage may also 
or instead be remote from the IP Proxy system 18, such 
as in a storage medium accessible by the IP Proxy sys- 
tem 18 through a local area network (LAN) connection 
or even a WAN like the Internet. This example allows 
sharing of a single directory of connection handlers 
among all IP Proxy systems 18 that can communicate 
with the connection handler store. It would also be pos- 
sible to have third parties extend the connection handler 
set by embedding the URL where the connection handler 
java class can be found. 

[0037] If connected to the Internet, a connection han- 



dler directory could potentially be accessed and thus 
shared by all Internet-connected IP Proxy systems 18. 
Public Internet-connected connection handler directories 
would preferably receive connection handler requests 

5 from IP Proxy systems 1 8 and in response transmit any 
requested connection handlers to the requesting IP 
Proxy system 18. A new connection handler may be re- 
quired by an IP Proxy system 1 8 when a mobile device 
12 which communicates with thelP Proxy system 18 

10 downloads a new software application or invokes a new 
mobile device feature which uses a new connection 
scheme or a connection method that was not previously 
used by the mobile device 12. A mobile device user or 
the new application or feature may then send a control 

IS message to the IP Proxy system 18, indicating, for ex- 
ample, the name of the required connection handler, per- 
haps the mobile device application that requires the new 
connection handler, and an address associated with a 
connection handler directory from which the new con- 

20 nection handler may be requested. The IP Proxy system 
18 would then preferably request the new connection 
handler from the directory. A connection handler direc- 
tory could be implemented for example as a web server 
accessible to an IP Proxy system 18 using HTTP re- 

25 quests. 

[0038] When a connection handler is loaded from a 
remote source, the IP Proxy system 18 preferably stores 
the handler in a local store in order to provide for faster 
loading of the handler for subsequent operations involv- 

30 ing the corresponding type of connection for either the 
mobile device 12 for which the connection handler was 
initially loaded from the directory or a different mobile 
device 12 supported by the IP Proxy system 1 8. Depend- 
ing upon the memory resources available to an IP Proxy 

35 system , downloaded connection handlers may be stored 
indefinitely or for a particular period of time. Alternatively, 
a least recently used or LRU replacement scheme could 
be used to provide for more efficient use of available 
memory by overwriting relatively less frequently used 

^0 connection handlers when new handlers are download- 
ed. Other memory management techniques could also 
be used to optimize local IP Proxy system connection 
handler storage arrangements. 

^5 Transcoding 

[0039] Relative to computer networks such as the In- 
ternet, wireless communication networks are slow. Any 
program that bridges the two, as an IP Proxy system 

so does, may have to transform Internet data so that it is 
formatted appropriately for a wireless network and mobile 
device. This process is referred to herein as filtering or 
transcoding, and usually involves such operations as 
compressing data from the Internet into a more compact 

ss format appropriate for wireless transmission and display 
on a relatively small mobile device display screen. 
[0040] In the following description, transcoding oper- 
ations are illustrated primarily in the context of the above 
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example of an HTTP handler 26 and HTTP connection. 
The HTTP connection and handler example is particu- 
larly useful in that HTTP allows content tags in the form 
of Multipurpose Internet Mail Extension (MIME) types, 
which may be used In some embodiments to determine 
an appropriate transcoder for received infomiation. 
[0041] In an IP Proxy system 18, there may be a single 
configuration file for each type of connection handler. In 
the IP Proxy system 18 for example, a single configura- 
tion file associated with the HTTP connection handler 26 
may include information for ail HTTP content transcod- 
ers. This configuration file is used to map transcoders to 
certain keys. The IP Proxy system 18 may consult this 
file to determine which content transcoders are available 
to manipulate any received content destined for a mobile 
device. 

[0042] In the configuration file, general rules are pref- 
erably specified for how to define the mapping between 
content types and transcoders. One example of a possi- 
ble configuration file entry is as follows: 
Entry = {[default]: {RSV | <Transcoder name>}} | 
{ [[InputType] | < ->OutputType>] : [Transcoder name] } 
where 

default indicated to the IP Proxy system which trans- 
coder should be loaded in case there is no one trans- 
coder associated with a received content type or con- 
nection request; 

RSV is a set of reserved keywords that is used in 
configuration file, such as pass (i.e. forward data to 
the mobile device without transcoding) or discard 
(i.e. do not transcode or fonward data to the mobile 
device); 

Transcoder name is the name of the mapped trans- 
coder; 

InputType indicates the input content type that the 
mapped transcoder can accept, which for an HTTP 
transcoder configuration file may be a MIME type; 
and 

OutputType indicates the output type, such as a 
MIME type for an HTTP transcoder that the trans- 
coder can produce. 

[0043] By using a content transcoder configuration file, 
new transcoders may be added for use by an IP Proxy 
system 1 8. Therefore, as new transcoders are developed 
and become available, they can be added to the config- 
uration file for any appropriate connection handlers and 
can thereafter be loaded by a connection handler when 
required, and without affecting other components of the 
IP Proxy system 18. For example, configuration file en- 
tries may be added without shutting down the entire IP 
Proxy system 1 8, thus allowing dynamic expansion of 
data that can be converted for transmission to mobile 



devices 12. 

[0044] In another example, a common configuration 
file fomriat for all connection handlers is used, and thus 
a only single configuration file entry need be prepared 
s and can be added to the configuration file for any con- 
nection handler. The concept of a common configuration 
file format for all connection handlers can be further ex- 
tended to providing a single configuration file for an IP 
Proxy system 18. Such a configuration file could then be 
used by all connection handlers in the IP Proxy system 
1 8 to determine which content transcoders are available 
and to select a particular transcoder for received content. 
However, it should be understood that a common con- 
figuration file format is in no way required. Some connec- 
tion handlers may share a configuration file entry format 
or even a single configuration file, whereas others sup- 
ported by the same IP Proxy system 18 may have differ- 
ent configuration files and entry formats. 
[0045] The IP Proxy system may load and execute a 
transcoder based on either the type of infomiation to be 
sent to a mobile device 12, or a transcoder name spec- 
ified by a mobile device 12 or an information source 20 
to transcode data being sent to a mobile device. 
[0046] A transcoder may instead be selected based 
upon information other than content types, including in- 
formafion in a header portion or other portion of a con- 
nection request from a mobile device, a response to an 
information request, or a communication from an infor- 
mation source including information to be pushed to a 
mobile device. For example, an IP Proxy system 18 may 
be configured to determine a type or the mobile device 
1 2 to which data is to be sent. According to the invention, 
transcoder selecfion by the IP Proxy system 18 is based 
on a network address or other identifier of the mobile 
device 12. Mobile device- or device type-dependent 
transcoder selection schemes may be supported by pro- 
viding a device or device type mapping table accessible 
to the IP Proxy system 1 8, which maps devices or device 
types to transcoders. Alternatively, a configuration file 
may be adapted to include device or device type identi- 
fiers to thereby associate particular transcoders with de- 
vices or device types. 

[0047] In a similar manner, transcoders may be select- 
ed based on an address (such as a URL) or other iden- 
tifier of an information source, to enable information 
source-specific transcoding. A mapping table or a con- 
figuration file accessible to an IP Proxy system such as 
18, may be used to enable transcoder selection based 
on information source. This type of transcoder selection 
may be useful, for example, when a particular transcoder 
is to be used to transcode any content that originates 
from a specific website and is destined for a mobile de- 
vice. 

[0048] Although content type-based and specified 
transcoder selecfion are the primary types of transcoder 
selecfion scheme described below, any of these alterna- 
tive schemes may be used instead of content type-based 
transcoder selecfion. The alternative schemes may also 
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be used to select a transcoder, for example, when a trans- 
coder Indicated by a primary transcoder selection 
scheme is not available, such as when a transcoder sys- 
tem does not Include a transcoder configured to trans- 
code a received content type into a content type that the 
mobile device is configured to accept. 

Pushing Information from an Information Source to a 
Mobile Device 

[0049] As described above, an IP Proxy system 18 
may support both outbound and inbound connections. 
However, this application relates primarily relates to 
pushing information to a mobile device via inbound con- 
nections. 

[0050] A server or information push operation differs 
from information request/response operations, such as 
those normally associated with web browsing for exam- 
ple, in that an information source 20 sends content to a 
recipient without receiving a request to do so. A mobile 
device 12 may register for service with a particular push 
service by establishing such settings as the particular 
information that should be pushed to the mobile device 
12, a push period or frequency with which Information 
should be pushed to the mobile device 1 2, a content type 
or transcoder that should be used for information des- 
tined for the mobile device 1 2, and possibly other settings 
related to information push operations. These settings 
may be established using the mobile device 12 Itself or 
some other interface to a push server 42, such as a web 
page for example. It should also be appreciated that an 
IP Proxy system 18 preferably exercises some level of 
access control. Each push server 42 may be required to 
register with an IP Proxy system 18 in order to commu- 
nicate with mobile devices 12. Control settings could be 
established at an IP Proxy system 18 by an IP Proxy 
system owner or operator or possibly remotely by a mo- 
bile device user to restrict push operations to particular 
registered IP Proxy systems 1 8. Access controls may be 
customized on a per-device, device group or IP Proxy 
system-wide basis. 

[0051] Fig. 5 is a signal flow diagram of an example 
Information push operation. Fig. 5 shows only those com- 
ponents of the IP Proxy system 18 directly involved in an 
HTTP-based push operation, In order to avoid congestion 
in the drawing. 

[0052] In the example of Fig. 5. content is sent from 
the push server 42 to the I P Proxy system 1 8 in a con- 
nection request. For an HTTP-based operation, the push 
may be an HTTP post operation, in which the push server 
42 submits an HTTP post request to the IP Proxy system 
1 8. The post request encloses header fields which spec- 
ify a resource associated with the IP Proxy system 18, 
as a Uniform Resource Identifier (URI) for example, and 
preferably include an indication of the type of content, 
such as a MIME type of Wireless Markup Language 
(WML) in Fig. 5. In an HTTP connection request, the 
MIME type of WML may be specified In a Content-Type 



field of an HTTP request header. 
[0053] The URI in the connection request from the 
push server 42 preferably specifies a resource that the 
IP Proxy system 18 associates with a particular destina- 
5 tion mobile device 1 2 or group of mobile devices 12. For 
example, the IP Proxy system 18 may establish a re- 
source for each mobile device 12 that has been config- 
ured for operation with the particular IP Proxy system 1 8. 
Such device-specific resources may for example be iden- 
10 tified using a mobile device identification number that the 
IP Proxy system 18 can map to an address of the mobile 
device 12 in the wireless network 14. Any information 
posted to a resource by a push server 42 is then forward- 
ed to the corresponding mobile device 12, as will be de- 
is scribed in further detail below. Altematively, an IP Proxy 
system 18 may manage a single resource to which infor- 
mation to be pushed to any mobile devices 1 2 configured 
for operation with the IP Proxy system 1 8 may be posted. 
In such embodiments, a post request would provide ad- 
ditional information to identify any mobile device(s) 12 to 
which the posted information is to be sent. 
[0054] The connection request from the push server 
42 is received by the push service module 30. In the 
example of Fig. 5, the push operation is HTTP-based, 
and the push services module 30 therefore Invokes the 
HTTP handler 26. It should be appreciated that different 
push services may be associated with respective han- 
dlers in an IP Proxy system 1 8, and that a single IP Proxy 
system 18 may provide several different push services. 
It is also contemplated that multiple push service mod- 
ules may be associated with a single connection handler. 
Alternatively, a single push services module may be func- 
tionally similar to the dispatcher 22 and provide an Inter- 
face between a push server 42 and any handler in an IP 
Proxy system 18. For the purposes of clarity however, 
only a single push service module 30 associated with the 
HTTP handler 26 is shown in Fig. 5. 
[0055] Although the connection request from the push 
server 42 in Fig. 5 is described as an HTTP request, it 
should also be appreciated that the connection request 
may possibly conform to some other protocol used for 
communications between the IP Proxy system 18 and a 
push server 42. A connection request may conform to a 
first protocol, possibly a proprietary protocol, for example, 
but could specify that a particular connection handler for 
a second protocol should be used to handle the connec- 
tion, such that the connection request is interpreted as a 
connection request according to the second protocol. 
Therefore, references herein to HTTP connection re- 
quests include connection requests that conform to other 
protocols but are Interpreted as HTTP connection re- 
quests. 

[0056] The HTTP handler 26 determines if the infor- 
mation in the post request from the push server 42 should 
be transcoded before it is sent to the mobile device 12. 
This may be accomplished, for example, by establishing 
a preferred content type for information destined for a 
mobile device 12. In Fig. 5, this content type is shown as 
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a tokenized, compressed version of WML which is gen- 
erally referred to Compiled WML or simply WMLC. The 
HTTP handler 26 then uses the received content type 
(WML) to perform a lookup in the configuration file 72. 
shown in the transcoding system 28 in Fig. 5. It will be 
appreciated by those skilled in the art however, that the 
configuration file 72 might instead be external to the 
transcoding system 28, part of the HTTP handler 26, or 
even external to the IP Proxy system 18, provided that 
the HTTP handler 26 can access the file. In one embod- 
iment, the configuration file will be stored in a data store 
accessible by the IP Proxy system 18, typically on the 
same computer system on which the IP Proxy 1 8 is run- 
ning. In another embodiment, the transcoder selection 
may instead be controlled by the push server 42 by spec- 
ifying in the request a content type or transcoder to be 
used for transfer to the mobile device 12, as described 
in further detail below. 

[0057] The HTTP handler 26 searches the configura- 
tion file 72 to determine which if any of its associated 
transcoders can transcode the received content type, 
WML, into WMLC for transmission to the mobile device 
12. In one embodiment, a lookup table which maps input 
content types to output content types for all configured 
transcoders is constructed when transcoders are first 
loaded to the IP Proxy system 18. In Fig. 5, the configu- 
ration file 72 or alternatively a lookup table, includes en- 
tries for two transcoders, one for converting from WML 
to WMLC and the other for converting from Hypertext 
Markup Language (HTML) to WMLC. The HTTP handler 
26, having found the configuration file entry for the WML- 
>WMLC transcoder, then loads the WML->WMLC trans- 
coder 74 from a local store for example, and executes 
the transcoder to convert the received WML content in 
the post request into WMLC. The WMLC content is then 
forwarded to the mobile device 1 2, through the dispatcher 
22. Although Fig. 5 shows the dispatcher 22 handling the 
communication of the WMLC content to the mobile de- 
vice 12. similar protocol translation or conversion be- 
tween HTTP used by the handler 26 and a communica- 
tion protocol used by the mobile device 12 may instead 
be performed by the HTTP handler 26 or another IP Proxy 
protocol translation/conversion module. 
[0058] If the information in a connection request from 
a push server 42 is already in the preferred content type, 
then no transcoding may be required. In Fig. 5, if the 
HTTP post request from the push server 42 included WM- 
LC content, then the HTTP handler 26 would preferably 
foHA^ard the WMLC content to the mobile device 12 with- 
out transcoding. 

[0059] Transcoding of pushed information is in no way 
restricted to single-transcoder operations. In the example 
of Fig. 5. each transcoder converts directly from one for- 
mat into WMLC. However, it Is contemplated that multiple 
transcoders may be used to convert received content 
into a format or type that the mobile device 12 is config- 
ured to accept. 

[0060] Fig. 6 is a signal flow diagram showing multiple 



or "chained" transcoding operations for an HTTP-based 
push operation. As in Fig. 5, Fig. 6 shows only those 
components of the IP Proxy system 18 directly involved 
in an HTTP-based push operation in order to avoid con- 

5 gestion In the drawings. The components shown in Fig. 
6 are substantially the same as those shown in Fig. 5 
and operate similarly thereto. The push server, configu- 
ration file 78 and transcoders shown in Fig. 6 are labelled 
differently than in Fig. 5 to indicate that information or 

10 content types that these components generate or proc- 
ess may be different. The components themselves may 
otherwise be the same. For example, push server 80 may 
be similar to push server 42 except that push server 80 
generates HTML content. It should also be appreciated 

15 that push server 80 could actually be the same server as 
push server 42 if push server 42 is configured to generate 
both WML and HTML content. Similarly, the configuration 
file 78 may store entries having the same format as those 
in configuration file 72, but is labelled differently since 

20 different entries are shown. Transcoders 82 may also be 
implemented in the same manner as transcoder 74, but 
the example transcoders 82 process different content 
types than the transcoder 74. 

[0061] An HTTP post request is sent from the push 

25 server 80 to the IP Proxy system 18, possibly through 
one or more intervening networks and interface compo- 
nents. In Fig. 6, the post request from the push server 
80 includes information of HTML content type, specified 
in a request header field for example as a MIME type of 

30 HTML. As described above, the push service module 30 
recognizes the request as an HTTP request and loads 
the HTTP handler 26. Although Fig. 6 shows the same 
push service module 30 as Fig. 5, a connection request 
for the push server 80 could be handled by a different 

35 push service. The HTTP handler 26 then consults the 
configuration file 78, searching not only for transcoders 
that output WMLC, but also for transcoders that output 
content types that may be Input to any transcoder that 
outputs WMLC. In Fig. 6, the HTTP handler 26, perhaps 

^0 in a first search pass through the configuration file 78, 
finds the WML->WMLC transcoder entry. The HTTP han- 
dler 26 may then repeat the configuration file search for 
any transcoders such as the HTML->WML transcoder 
that convert content into WML, which it can convert into 

<s WMLC content type. If a content type other than WML 
and HTML were provided in the post request from the 
push server 80, then the configuration file search may 
be further repeated by the HTTP handler 26, depending 
for example on acceptable delays in post request 

so processing. 

[0062] In order to avoid the delays and demand on 
processing resources associated with such multiple 
search passes through a configuration file, a transcoder 
content type lookup table may be used. When transcod- 

55 ers are first installed in an IP Proxy system 18, a com- 
prehensive mapping table is preferably constructed to 
map received content types to possible output content 
types. For example, in Fig. 6. a lookup table entry for 
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WMLC content would indicate that either WML or HTML 
can be converted Into WMLC. Such a table would also 
preferably Indicate that HTML to WMLC transcoding in- 
volves two stages of transcoding. The table might instead 
be organized into single- and chained-transcoding sec- 
tions, whereby if only a single transcoding operation is 
preferred, the single-transcoderpartofthe table including 
an entry for the WML->WMLC transcoder would be ac- 
cessed. If further transcoding operations and the asso- 
ciated processing operations and time delays are accept- 
able, then the HTTP handler 26 may perform a lookup 
of a received content type or possibly an input type for a 
previously identified transcoder in a chained-transcoder 
section of the table. Preferably, the format of the trans- 
coding configuration file may be changed to represent 
just such a lookup table in order to speed up the search. 
This may be accomplished, for example, by specifying a 
path between content types involving multiple transcod- 
ers. 

[0063] It Is also feasible for a chain of transcoders to 
include both local and remote transcoding services. 
These remote transcoding services could be transcoder 
files that an IP Proxy system 18 discovers, downloads 
and executes or they could be web based transcoding 
services which receive data in one fomriat and return it 
in another, as described in further detail below. 
[0064] The determination regarding whether or not 
multiple transcoding operations will be permitted may be 
made by the HTTP handler 26 either before or after the 
table or configuration file lookup operation is performed. 
In the example of Fig. 6, it should be apparent that mul- 
tiple transcoders may be invoked to convert received 
content into WMLC. 

[0065] Once the configuration file entries for the HTML- 
>WML and WML->WMLC transcoders are found in the 
configuration file 78 by the HTTP handler 26, the HTTP 
handler 26 first loads and executes the HTML->WML 
transcoder to transcode the received HTML content into 
WML. The HTTP handler then loads and executes the 
WML->WMLC transcoder on the WML result of the first 
transcoding operation. The resultant WMLC content is 
then forwarded to the dispatcher 22 and then to the mo- 
bile device 12. When WMLC content is returned by the 
push server 80, the HTTP handler 26 fonwards the con- 
tent to the dispatcher 22 without transcoding, whereas if 
WML content is returned, the WML->WMLC transcoder 
would be invoked, as described above. 
[0066] The determination as to whether or not multiple 
transcoding operations are allowed may also be made 
dependent upon predetermined criteria such as maxi- 
mum HTTP request processing time or maximum content 
transcoding time or processor time for example. This de- 
termination might also take mobile device user- or push 
server-specified priority into account. If high time priority 
(low time delay) is assigned by a mobile device 12 user 
for information destined for the user's mobile device 12, 
then single transcoder operations may be selected. Al- 
ternatively, if a high data priority Is associated with infor- 



mation to be sent to a mobile device 1 2, then any number 
of chained transcoder operations may be allowed in order 
to get the information to the mobile device 12 in an ac- 
ceptable format. User settings could be applicable to alt 
5 pushed information, certain types of pushed information, 
or information originating from certain specific push serv- 
ers. Transcoding could also or instead be controlled by 
a push server, as described in further detail below. 
[0067] Other criteria which may be applied by a con- 
nection handler include but are in no way limited to al- 
lowing chained transcoders only for relatively small 
amounts of received content, only at certain times of day, 
under specific current traffic conditions, or only when the 
configuration file or lookup table is stored in a local file 
system. Further criteria will be apparent to those skilled 
in the art and as such remain within the scope of the 
present application. 

[0068] It is also possible that more than one multiple- 
transcoder chain may be available to convert between 
any two content types. In such situations, there may be 
some priority, based for example on transcoding cost or 
fidelity, that an IP Proxy system 1 8 uses to select between 
several available chains. 

[0069] in the above examples of push operations, the 
push server 42 or 80 indicates the content type of infor- 
mation in the connection request to the IP Proxy system 
18. However, if a push server pushes data content but 
does not specify a content type, then the default trans- 
coder is preferably used. If the default transcoder dis- 
cards received content or outputs a content type that can- 
not be accepted by the mobile device, 12 an error mes- 
sage is preferably returned to the push server, which may 
then re-send the data to the mobile device 12. The error 
message further preferably indicates to the server a rea- 
son for any delivery failure, such that the push server 
may attempt to remedy the delivery problem if possible 
before the data is resent. Where the data could not be 
delivered to the mobile device 12 because no content 
type was specified and the default transcoder could not 
transcode the data into an acceptable content type, for 
example, then the push server may re-send the data with 
an appropriate content type. 

[0070] The above illustrative examples also assume 
that the IP Proxy system 1 8 knows that the mobile device 
12 can accept WMLC content, or at least that WMLC is 
a preferred content type for mobile device-destined in- 
formation. If the IP Proxy system 18 does not know which 
content type(s) that the mobile device 12 can accept, 
then the default transcoder is preferably used. Alternate- 
ly, the active connection handler, the HTTP handler 26 
in Figs. 5 and 6, may instead consult the transcoder con- 
figuration file 72, 78 or lookup table to determine if a trans- 
coder that accepts the returned content type as input is 
available. If an available transcoder is found, then it is 
loaded and used to transcode the received content. If 
more than one such transcoder is found, then one of 
them, for example the transcoder having the first entry 
in the configuration file or the transcoder that was used 
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most recently to transcode data for the particular mobile 
device 1 2 to which the content is destined, may be loaded 
and executed. In Fig. 6 for example, if no preferred con- 
tent type is known by the IP Proxy system 18. then the 
HTML->WML transcoder would be loaded and executed 
and the resultant WML content could then be returned 
to the mobile device 12. 

Specifying a Content Transcoder from a Push Server 

[0071] A connection request from a push server may 
also specify that a particular transcoder be used to trans- 
code any content to be pushed to a mobile device 12. 
For an HTTP connection for example, an IP Proxy system 
18 may be configured to expect a Content-Transcoder 
field in an HTTP request header to indicate that a push 
server 12, which may, for example, be associated with a 
mobile device software application or feature, Is specify- 
ing a particular transcoder. The IP Proxy system 18 will 
load and execute the specified transcoder to transcode 
the pushed content. The Content-Transcoder header 
field should have a value that is valid in the context of 
the HTTP configuration file, or where another connection 
handler is used, its corresponding configuration file. 
[0072] If a requested transcoder Is not available, then 
an error message will preferably be sent back to the push 
server 42, for example in the form of an lOException In- 
dicating that the requested transcoder is not available. 
The push server 42 may then have the option to retry the 
request with a different transcoder. When the pushed 
information is intended for a mobile device software ap- 
plication or component that requires Information in a par- 
ticular format available only from the specified transcoder 
however, the request may instead be retried at a later 
time when the specified transcoder may possibly be 
available. 

[0073] Transcoder selection In a connection request 
from a push server 42 will now be described in further 
detail by way of an illustrative example of an HTTP-based 
push operation. Fig. 7 is a signal flow diagram of an ex- 
ample of push server-controlled transcoder selection for 
an HTTP-based push operation. As above. Fig. 7 shows 
only those components of the IP Proxy system 1 8 directly 
Involved in an HTTP-based server push operation. 
[0074] In Fig. 7, content Is pushed from the push server 
42 to the IP Proxy system 18. For an HTTP-based oper- 
ation, the push may be an HTTP post operation, as de- 
scribed above. The post request encloses header fields 
in which at least a transcoder name (WML->WMLC in 
this example) and possibly an indication of the type of 
content, such as a MIME type of WML in Fig. 7, may be 
specified. Since the content Is provided by the same en- 
tity that selects the particular transcoder, the content type 
will normally be compatible with the specified transcoder 
and therefore need not necessarily be specified in the 
post request. 

[0075] The post request from the push server 42 is 
received by the push service module 30. In the example 



of Fig. 7, the push operation is HTTP-based, and the 
push service module 30 therefore invokes the HTTP han- 
dler 26. As In Figs. 5 and 6, although only a single push 
service module 30 associated with the HTTP handler 26 

5 is shown in Fig. 7, an IP Proxy system 18 may include 
multiple push service modules, or the module 30 may be 
may be associated with multiple connection handlers. 
[0076] The example connection request shown in Fig. 
7 specifies the particular transcoder In terms of Its input 

10 content type (WML) and output content type (WMLC). 
However, other transcoder naming conventions are also 
possible. When a configuration file has entries in a format 
as described above, part of the file entry for each trans- 
coder indicates Its respective Input and output content 

IS types. The "Transcoder Name" field in such a configura- 
tion file entry therefore need not necessarily also include 
the Input and output content types. Although many dif- 
ferent transcoder naming schemes are possible, a par- 
ticular transcoder is preferably specified in any mobile 

20 device requests and configuration files using the same 
name. 

[0077] The HTTP handler 26 preferably uses the trans- 
coder name in the post request, WML->WMLC in Fig. 7, 
to perform a lookup In the configuration file 72 to deter- 

25 mine if the specified transcoder is available in the IP 
Proxy system 18. It should be appreciated that the con- 
figuration file 72 might be part of the transcoding system 
28 as shown in Fig. 7, external to the transcoding system 
28, part of the HTTP handler 26. or external to the IP 

30 Proxy system 18. 

[0078] In Fig. 7, an entry for the transcoder specified 
in the post request exists in the configuration file 72. The 
WML->WMLC transcoder 74 is therefore available to the 
IP Proxy system 1 8, and the transcoder 74 is loaded and 

35 executed to transcode the WML content enclosed In the 
post request into WMLC content. The WMLC content is 
forwarded to the mobile device 1 2, through the dispatcher 
22. When content is provided by a push server 42 in a 
mobile device-acceptable format, WMLC in the example 

40 of Fig. 7, the post request may specify a null or other 
predetermined value in an appropriate request header 
field to specify that the content should be forwarded to 
the dispatcher 22 without transcoding. It is also contem- 
plated that a push service module 30 may be configured 

45 to directly manage the transcoding of pushed content, 
instead of invoking a separate connection handler. 
[0079] If the particular transcoder specified in the post 
request from the push server 42 is not available to the 
IP Proxy system 18, then the push operation may be 

50 aborted. Alternatively, a different transcoder having an 
input content type and output content type respectively 
compatible with the content from the post request and a 
content type accepted by the mobile device 12 (if known 
to the IP Proxy system 18) may be used. Any time the 

55 requested transcoder could not be used to transcode 
pushed content, a push operation failure or error mes- 
sage may be returned to the push server 42, particularly 
if the push server 42 is configured to retry undelivered 
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content. Since pushed content was not requested by the 
mobile device 12, no such error or failure message would 
typically be sent to the mobile device 1 2. When the default 
or any other transcoder Is used instead of the specified 
transcoder, then the push server 42 may be infomned of 5 
the particular transcoder that was used. 
[0080] Any such alternate transcoding operations may 
instead be controlled by the push server 42. For example, 
when the transcoder configuration file 72 does not In- 
clude an entry for the specified WML->WMLC transcod- 
er, the IP Proxy system 18 may send a failure or error 
message to the push server 42 indicating that the spec- 
ified transcoder is not available or cannot be used, as 
described above. The push server 42, a server software 
application associated with the connection request, or an 
operator or administrator of push server 42 may then 
respond to the message indicating the action to be taken. 
This action may include, for example, fonwardlng the con- 
tent to the mobile device 1 2 without transcoding, invoking 
the default transcoder, Invoking a different particular 
transcoder specified by the push server 42, or discarding 
the content. The push server 42 may also set a trans- 
coder substitution policy, such as no transcoder substi- 
tutions allowed, chained transcoders allowed, etc., In the 
original connection request sent to the IP Proxy system 
18. 

[0081] The IP Proxy system 18 may also determine 
which ifanyofthe transcoders with corresponding entries 
in the configuration file 72 may transcode the pushed 
content into either the output content type of the trans- 
coder specified in the connection request or other content 
types, and identify such available transcoders in the fail- 
ure or error message sent to the push server 42. The 
push server 42, software application or operator may 
then use this infomnation to determine if any of the avail- 
able transcoders should be used to transcode the pushed 
content. For instance, if the content cannot be transcoded 
by the specified transcoder into a format required for par- 
ticular processing operations at the mobile device 1 2. but 
a second transcoder is available to transcode the re- 
turned content into a content type that can be viewed on 
the mobile device 12, then the push server 42 may re- 
submit the content and/or specify the second transcoder. 
Although the originally intended processing operations 
might not be possible using content that was transcoded 
using the second transcoder, the user is able to at least 
view the content. 

[0082] In order to avoid sending connection requests 
that specify unavailable transcoders, it may be desirable 
for the push server 42 to query the IP Proxy system 18 
for a list of available transcoders prior to issuing a con- 
nection request. A connection request can then be pre- 
pared using one of the transcoders known to be available 
to the IP Proxy system 18. If a required transcoder is not 
available at an IP Proxy system 18, then the push server 
42 may query other IP Proxy systems in an attempt to 
find the required transcoder, prepare a connection re- 
quest specifying an alternate but available transcoder or 



abort an information request operation involving the re- 
quired transcoder. 

[0083] The signal flow diagram of Fig. 7 shows a single 
content transcoder in a server data push via an HTTP 
post operation. It should be apparent that a server may 
specify more than one content transcoder, to be used for 
example in a chained transcoding operation. 

External Transcoder Systems 

[0084] As described briefly above, transcoders may be 
loaded as needed from a local store on a computer sys- 
tem on which an IP Proxy system 18 has been imple- 
mented. Transcoders may also be loaded from an exter- 
nal store. Fig. 8 is a general block diagram of a commu- 
nication system with an external transcoder system. 
[0085] The system 90 shown in Fig. 8 is similar to sys- 
tem 10 of Fig. 1 except forthe external transcoder system 
86. Elements common to both systems 10 and 90 have 
been described above. As shown by the dashed lines In 
Fig. 8, the IP Proxy system 84 may communicate with 
the transcoder system 86 through some sort of direct 
connection such as a serial port or connection, through 
a WAN 16 such as the internet, or through a LAN 88 
within which the IP Proxy system 84 and the transcoder 
system 86 are configured to operate. Other communica- 
tion links between the IP Proxy 84 and the transcoder 
system 86 will be apparent to those skilled in the art. 
[0086] Fig. 9 is a signal flow diagram illustrating an 
HTTP-based push operation with an external transcoder 
system such as shown in Fig. 8. As in the preceding ex- 
amples, an HTTP post request is sent from the push serv- 
er 42 to the I P Proxy system 84, specifying a particular 
transcoder (WML->WMLC) and possibly indicating the 
content type, WML in this example. The connection re- 
quest shown in Fig. 9 is for illustrative purposes only, and 
need not necessarily include a content type indication or 
specify a particular transcoder. 
[0087] The request is received by the push service 
module 93 in the IP Proxy system 84, which determines 
that the request is an HTTP request and thus loads and 
invokes the HTTP connection handler 94. The HTTP han- 
dler 94 may be substantially similar to the HTTP handler 
26. although it operates somewhat differently than han- 
dler 26 to load content transcoders. The HTTP handler 
94 receives the request from the push service module 
93 and may then refer to a transcoder configuration file 
92 or a lookup table as described above to determine 
whether or not the specified WML->WMLC transcoder is 
available to convert content received in response to the 
request. If no transcoder is specified in the post request, 
then a transcoder may be selected based on a content 
type, substantially as described above. 
[0088] The WML content in the HTTP post request 
from the push server 42 is preferably stored in a file sys- 
tem or other data store 98, which may be the resource 
identified by the URI in the request, while the appropriate 
transcoder is loaded. In the example of Fig. 9, the HTTP 
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handler 94 requests the specified WML->WMLC trans- 
coder from the transcoder system 86. Although this re- 
quest is shown in Fig. 9 as an HTTP request from the 
HTTP handler 94, It should be apparent that other transfer 
mechanisms might instead be used by an IP Proxy sys- 
tem 84 to retrieve a transcoder from a remote transcoder 
system. For example, if the IP Proxy system 84 commu- 
nicates with the transcoder system 86 via a LAN 88 (Fig. 
8), then a LAN protocol or data access and transfer 
scheme could be invoked by the HTTP handler 94 in 
order to retrieve any required transcoders. The push 
service module 93 in the IP Proxy system 84 may instead 
be configured to retrieve the specified transcoder from 
the transcoder system 86, possibly through a connection 
handler. 

[0089] In Fig. 9, the transcoder system 86 locates the 
requested WIVIL->WMLC transcoder among its available 
transcoders 96 and returns the requested transcoder to 
the IP Proxy system 84. Regardless of the particular 
transcoder transfer mechanism implemented, the IP 
Proxy system 84, or in the example of Fig. 9 the HTTP 
handler 94, receives and executes the returned WML- 
>WMLC transcoder, as indicated at 100. The previously 
received and possibly stored WML content may then be 
processed by the transcoder 100, and the transcoded 
content is returned to the mobile device 12 by the dis- 
patcher 22. 

[0090] If chained transcoder operations are specified 
in the connection request from the push server 42, then 
more than one transcoder request may be made by the 
IP Proxy system 84 to the transcoder system 86. Multiple 
transcoders may instead be requested in a single request 
to the transcoder system 86. Processing of previously 
received content for chained transcoder operations may 
proceed either as each required transcoder is loaded by 
the IP Proxy system 84, with intermediate transcoded 
content possibly being stored in a file system or data 
store such as 98, or only when all required transcoders 
have been loaded. 

[0091] When a transcoding operation is complete, a 
transcoder loaded from the external system 86 is prefer- 
ably stored locally by the IP Proxy system 84 in order to 
avoid subsequent requests to the external transcoder 
system 86 for the same transcoder. Retrieval and loading 
of a transcoder from a local or internal store in the IP 
Proxy system 84 will typically be completed much faster 
than a request to a remote system and reduces traffic on 
the communication link between the IP Proxy system 84 
and the transcoder system 86. In such IP Proxy systems, 
the active connection handler, which is the HTTP handler 
94 in Fig. 9, preferably determines if a required transcod- 
er is stored In a local data store before requesting the 
transcoder from the external transcoder system 86. De- 
pending upon the amount of available storage, transcod- 
ers may be stored indefinitely or for a certain predeter- 
mined period of time. Other memory management 
schemes, such as over-writing stored transcoders on an 
LRU basis, for example, may also be used when memory 



resources are limited. 

[0092] The configuration file 92 or transcoder lookup 
table may be adapted for external transcoder loading by 
including an indication of the location of a transcoder in 

5 the configuration file or table entry for the transcoder. 
The file 92 or table is preferably updated if a transcoder 
is stored to, or overwritten in, a local memory, such that 
the active handler can determine from the initial lookup 
operation whether or not the transcoder must be loaded 

^0 from the external transcoder system 86. When a trans- 
coder has not been or is no longer stored locally, then 
the file 92 or lookup table preferably indicates from where 
the transcoder may be retrieved. For a transcoder that 
may be retrieved through an HTTP connection, the cor- 

^5 responding file or table entry may indicate the IP address 
of the transcoder system 86, whereas a network address 
may be specified in the configuration file or lookup table 
when a LAN connection is used. If the location of a trans- 
coder system from which a specified transcoder is avail- 

20 able is known to a the push server 42, then the location 
may also or instead be included in the connection request 
from the push server 42. 

[0093] It is also contemplated that more than one ex- 
ternal transcoder system may be implemented in a com- 

25 munication system such as 90. In such.an arrangement, 
the configuration file 92 or lookup table would preferably 
include entries for all transcoders that are available to an 
IP Proxy system 84 through all of the external transcoder 
systems with which it can communicate. An I P Proxy 

30 system 84 may thereby download transcoders from any 
of a number of transcoder systems via direct or network 
connections. Overall operation of an IP Proxy system 84 
with multiple transcoder systems would be substantially 
as described above, except that different transcoder sys- 

35 tems may be accessed, possibly using different transfer 
mechanisms and communication protocols, for each da- 
ta transcoding operation. Chained transcoding opera- 
tions may also potentially involve communication with 
different transcoder systems. 

40 [0094] The configuration file 92 or lookup table is pref- 
erably arranged to facilitate a simple resolution scheme 
when a particular type of transcoder is available from 
more than one transcoder system. Although an IP Proxy 
system 84 may be able to access multiple transcoder 

<5 systems, anowneroradministratorofan IP Proxy system 
84 may designate one of these transcoder systems as a 
preferred or default system from which the IP Proxy sys- 
tem 84 first attempts to download a transcoder. The order 
of preference of transcoder systems for any transcoder 

50 available from more than one transcoder system may for 
example be reflected in the order of configuration file or 
lookup table entries. If the file or table is arranged by 
transcoder type, then entries conresponding to the most 
preferred sources for a particular transcoder are prefer- 

55 ably listed before entries associated with other transcod- 
er systems. The configuration file or lookup table may 
instead be arranged according to transcoder system , with 
all entries for the default or preferred transcoder system 
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occurring first. A preferred transcoder system might also 
be specified in a connection request from the mobile de- 
vice 12. In these example arrangements, an IP Proxy 
system 84 will preferably attempt to load a particular 
transcoder from a preferred source before accessing any 
other sources. 

[0095] If the specified transcoder could not be loaded 
by an IP Proxy system 84, then an error message may 
be returned to the push server 42. Any of the error or 
failure operations described above may be performed by 
the IP Proxy system 84 and push server 42 if the specified 
transcoder could not be used to transcode received con- 
tent. 

[0096] Fig. 1 0 shows a further signal flow diagram for 
an external transcoder system. In Fig. 10. not only the 
transcoder system 86, but also the configuration file 1 02 
is external to the IP Proxy system 84 and therefore may 
be shared among multiple IP Proxy systems. Communi- 
cations between an IP Proxy system 84 and the config- 
uration file 102 may be via a direct connection or a net- 
work connection, and may be different for different IP 
Proxy systems. For example, the configuration file 102 
may be maintained by an owner or operator of a particular 
IP Proxy system 84 which is linked to the configuration 
file by a direct communication link, whereas other IP 
Proxy systems may communicate with the configuration 
file 102 through local or wide area network connections. 
The configuration file 1 02 might also be maintained at 
the transcoder system 86. As above, the configuration 
file 1 02 may be implemented as a lookup table. The con- 
figuration file 1 02 may thus be considered a registry, with 
which one or more external transcoder systems such as 
86 register available transcoders. 
[0097] When an inbound connection request specify- 
ing a particular transcoder is received by the push service 
module 93 in the IP Proxy system 84, it is recognized as 
an HTTP request and the HTTP handler 94 is loaded and 
invoked by the push service module 93. As described 
above, the HTTP handler 94 determines if the specified 
transcoder Is available In the IP Proxy system 84 by con- 
sulting a configuration file. In the example of Fig. 1 0 how- 
ever, the configuration file 1 02 is remote from the IP Proxy 
system 84. If the configuration file 102 Is accessible via 
HTTP, then the HTTP handler 94 manages the transcod- 
er lookup function with the configuration file 102. if the 
configuration file 1 02 is not adapted for HTTP, then a 
different connection handler may be invoked to facilitate 
the transcoder lookup or configuration file search. Alter- 
natively, the push service module 93 may perform the 
transcoder lookup/search function. In the example of Fig. 
10, the configuration file 102 includes an entry for the 
specified WML->WMLC transcoder. 
[0098] As above, it Is assumed that the push server 42 
pushes WML content is to a mobile device 12. The trans- 
coding system 86 in the example shown in Fig. 10 in- 
cludes a set of remotely executable transcoders 104, 
comprising a WML->WMLC transcoder 104a and an 
HTML->WML transcoder 104b, and thereby enables re- 



mote transcoding of content. Instead of requesting and 
loading the WML->WMLC content transcoder 1 04a from 
the transcoder system 86, the HTTP handler 94, another 
connection handler, depending on the particular trans- 

5 coder system and the transfer schemes It supports, or 
possibly the push service module 93, transfers the WML 
content to the transcoding system 86. Within the trans- 
coding system 86, the appropriate WML->WMLC trans- 
coder 104a is executed and the WML content Is trans- 

10 coded into WMLC format. The WMLC content is then 
returned to the HTTP handler 94, or to another connec- 
tion handler if IP Proxy system 84 to transcoder system 
86 communications do not use HTTP. When the WMLC 
content is returned by the transcoding system 86 and 

15 received by the HTTP handler 94, possibly through an- 
other connection handler and/or the push service module 
93, it is forwarded to the dispatcher 22. The dispatcher 
22 then prepares a message including the WMLC content 
and sends the message to the mobile device 12. The 

20 HTTP handler 94 may instead prepare a message for 
transmission to the mobile device 12, which would then 
be translated (if necessary) by the dispatcher 22 to con- 
form to a communication protocol or scheme used by the 
mobile device 12. 

25 [0099] Illustratively, the WML content from the push 
server 42 may be stored by the HTTP handler 94 in case 
a data transfer or transcoding error occurs. Local storage 
of the WML content allows an IP Proxy system 84 to re- 
submit the content, to eitherthe same transcoder system 

30 86 or a different transcoder system. When a push oper- 
ation is accomplished via an HTTP post request as shown 
in Fig. 10, the pushed content may be available to the IP 
Proxy system 84 from the resource to which the content 
is posted. 

35 [01 00] If the content in the connection request from the 
push server 42 is HTML content, then the HTTP handler 
94 or push service module 93, through another handler 
if required, would submit the HTML content to the trans- 
coder system 86 for chained transcoding using both the 

40 HTML->WML transcoder 1 04b and then the WML->WM- 
LC transcoder 104a. Such chained transcoding opera- 
tions may also be specified by the push server 42 in the 
connection request. Chained transcoders may either be 
part of the same transcoding system 86 as shown in Fig. 

^5 10, or implemented in different transcoder systems. 
When a chained transcoding operation involves different 
transcoder systems, content from an information source 
may first be transmitted to one transcoder system for 
transcoding into an intermediate content type which is 

50 returned to the IP Proxy system 84, and the intermediate 
content type may then be sent to another transcoder sys- 
tem, for transcoding using the specified transcoder or 
another intermediate transcoder in a transcoder chain. 
Content Is preferably forwarded between different trans- 

55 coding systems via the IP Proxy system 84 which is 
processing the connection request, but may instead be 
directly transmitted from one transcoder system to an- 
other if compatible data transfer mechanisms have been 
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implemented in each transcoding system. 
[0101] Data request errors or failures, such as trans- 
coder errors or other situations in which a specified trans- 
coder is unavailable, may be managed according to any 
of the schemes described above, possibly including such 
further operations as using a different transcoderto trans- 
code content, returning an error message to the push 
server 42, and controlling any subsequent processing of 
a request or content from the push server 42. 
[0102] In addition, a push server such as 42 may con- 
sult an external configuration file to determine which 
transcoders are available to an I P Proxy system 84 before 
a push request is submitted. If a required type of trans- 
coder is not available, then the push server 42 may de- 
tennine If any other transcoder operation, Including 
chained transcoder operations, may be suitable for the 
push request and an intended recipient mobile device 12 
and format the push request accordingly, thereby possi- 
bly avoiding failures or enrors at the IP Proxy system 84. 
As described above, the configuration file 102 may be a 
registry including entries for transcoders available from 
one or more transcoder systems. When entries in the 
configuration file 102 include an address, such as an IP 
address, or other identifier of a transcoder system from 
which a particular transcoder is available, then the ad- 
dress may be supplied to an IP Proxy system 84 by a 
push server 42 in a push request. At least some trans- 
coder searching operations may thereby be off-loaded 
from IP Proxy systems 84 to push servers 42. 
[0103] In the system of Fig. 10, it is contemplated that 
the transcoder system 86 and configuration file 102 may 
communicate with each other to ensure that the config- 
uration file 102 accurately indicates which transcoders 
are available. A configuration file may be associated with 
a particular type of connection such as HTTP connec- 
tions and thus HTTP connection handlers. If a configu- 
ration file 1 02 is associated with a particular transcoder 
system 86, then the configuration file may be resident 
within the transcoding system 86. 
[01 04] If multiple transcoding systems are Implement- 
ed, a shared configuration file storing transcoder entries 
for the transcoders available in all transcoder systems 
may simplify the transcoder lookup performed by a con- 
nection handler. An IP Proxy system 84 or push server 
42 need then only consult a single configuration file to 
determine if appropriate transcoders are available from 
any transcoder systems with which it can communicate. 
This single configuration file/server could also support 
protocols to allow external transcoding servers to regis- 
ter. A registration process could add a list of available 
transcoders to the single configuration file for example. 
[0105] An external transcoding system 86 preferably 
supports a query function to allow a push server 42 to 
determine which transcoders are available before a con- 
nection request is prepared and sent to an IP Proxy sys- 
tem 84. Transcoders can also be added to the transcoder 
system 86 and configuration file 102. A push server 42 
may add a transcoder to the transcoding system 86 and 



push content that relies on the new transcoder to mobile 
devices such as mobile device 12 through the IP Proxy 
system 84. 

[01 06] External transcoder systems 86 include down- 
5 load systems from which transcoders may be download- 
ed by an IP Proxy system 84 and executed locally, as 
shown in Fig. 9, and remote transcoding systems to which 
content is sent for transcoding at the transcoding system 
as shown in Fig. 10. In another embodiment, a "hybrid" 
transcoder system incorporates both of these types of 
transcoder systems. When a hybrid transcoder system 
is available to an IP Proxy system 84, the IP Proxy system 
84 may either download a required transcoder from the 
transcoder system or send content to the transcoder sys- 
tem to be transcoded remotely. Alternatively, if the push 
server 42 knows the content type or transcoder that 
should be used for information to be sent to the mobile 
device 12, then the push server 42 may itself download 
a transcoder from or submit content for transcoding to 
an external transcoding system and include the trans- 
coded content in the connection request. This offloads 
transcoding from an IP Proxy system 84 to a push server 
42 and makes an information push operation independ- 
ent of transcoders available to an IP Proxy system 84. 
This concept of push server transcoding could be further 
extended to include transcoder downloading from an IP 
Proxy system 84 and local execution of the transcoder 
on a push server 42. 

[01 07] The selection of transcoder download or remote 
transcoding may be dependent, for example, upon the 
amount of data to be transcoded, the complexity of the 
transcoding (single or chained operations), a type of 
transcoding specified in a connection request, or other 
criteria. Similarly, chained transcoding operations may 
involve download transcoding systems and local trans- 
coder execution as well as remote transcoding systems. 
[01 08] External transcoding systems may also support 
such services as transcoder downloading or remote 
transcoding for a push server such as 42. A push server 
42 may be configured to manage transcoding of informa- 
tion content before the information content is pushed to 
the mobile device 12. In Fig. 10, for example, the push 
server 42 may consult the configuration file 1 02 to deter- 
mine whether an appropriate transcoder, a WML->WM- 
LC transcoder. Is available in a transcoder system. Since 
the transcoder system 86 includes a WML->WMLC 
transcoder 104a, the configuration file 102 would include 
an entry for the transcoder 1 04a and possibly an indica- 
tion of an address, such as a URL or IP address, for 
example, from which the transcoder is available. In Fig. 
10, the transcoder system 86 is a remote transcoding 
system, such that the push server 42 may submit the 
information content to be transcoded to the transcoder 
system 86. The push server 42 may therefore incorporate 
a connection handler which enables communication with 
the transcoder system 86. Transcoded WMLC content 
from the transcoder 104a would then be returned to the 
push server 42. The push server 42 preferably caches 
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the transcoded content in a local or remote data store 
accessible to the push server 42. The cached transcoded 
WMLC content may then be retrieved from the data store 
and pushed to a mobile device 12 through the IP Proxy 
system 84. A push request from the push server 42 pref- 
erably includes an indication that the information content 
to be pushed to the mobile device 12 has already been 
transcoded into a content type that the mobile device Is 
configured to accept. Since the information content in 
such a push request has been transcoded, it Is forwarded 
to the mobile device 12 by the push services module 93, 
through a connection handler such as the HTTP handler 
94, if necessary, and the dispatcher 22. 
[0109] Although "pre-transcoding" by a push server 
has been described above in the context of a remote 
transcoding system, it should be appreciated that infor- 
mation content may instead be locally transcoded by a 
push server 42 using a download transcoding system or 
a transcoding system provided at the push server 42. 

Example Implementation 

[01 1 0] An example implementation of an IP Proxy sys- 
tem will now be described. Fig. 1 1 is a block diagram 
showing an IP Proxy system 124 implemented in a secure 
network. 

[0111] The system 120 in Fig. 11 includes a. mobile 
device 12 that operates within a wireless network 14. 
Through a gateway 15, the mobile device can receive 
and preferably also send data over a WAN 16 such as 
the Internet. These elements of the system 120 are sub- 
stantially the same as similarly labelled elements in Fig. 
1. In the system 120 however, the IP Proxy system 124 
is configured within a private network such as a corporate 
network 130, behind a security firewall 127, and commu- 
nicates with the gateway 1 5 through a network server 
computer 122. In a particular example embodiment, the 
network server 1 22 is associated with an email system 
128. Two information sources, an internal push server 
126 and an external information source 132, are also 
shown in Fig. 11. 

[01 1 2] The network server 1 22 preferably enables se- 
cure communication to the mobile device 1 2, as indicated 
by the encryption and decryption blocks 122a and 122b. 
The network server 122 encrypts any communications 
directed to a mobile device 12. The intended recipient 
mobile device 12, using a secret key stored therein, can 
decrypt encrypted communications from the network 
server 122. A mobile device 12 similarly encrypts any 
information sent to the network server 1 22, which can be 
decrypted by the decryption module 122b. Those skilled 
in the art of cryptography will appreciate that the keys 
and encryption algorithms used at the network server 
122 and mobile device 12 are preferably chosen so that 
it would be computationally infeasible to decrypt encrypt- 
ed information without the required secret key. One pre- 
ferred encryption scheme is triple-DES (Data Encryption 
Standard). 



[01 1 3] Key distribution between a network server 1 22 
and a mobile device 12 may be accomplished via a se- 
cure connection such as a secure physical connection 
between the mobile device 12 and the network server 
5 1 22, or between the mobile device 1 2 and another com- 
puter within the corporate network. Known public key 
cryptography techniques may instead be used for key 
distribution. In a public key scheme, a public key Is used 
to encrypt information in such a way that the encrypted 
information may be decrypted using a corresponding pri- 
vate key. The public key is stored by, and may be re- 
trieved from, a publicly accessible key repository com- 
monly referred to as a certificate authority or CA, whereas 
the private key is stored only at a mobile device or system 
with which the public key Is associated. Thus, a network 
server 122 or any other sender that wishes to send en- 
crypted information to a mobile device 12 may retrieve 
the mobile device's public key from a CA and use the 
public key to encrypt information destined for the mobile 
device 1 2. A mobile device 1 2 may similarly obtain a net- 
work server's public key from a CA and use the public 
key to encrypt communication signals to be sent to the 
server. 

[0114] Regardless of the particular key distribution 
scheme and encryption techniques used, encrypted 
communications between a mobile device 12 and net- 
work server 122 may be used, for example, where cor- 
porate or other private information is to be accessed us- 
ing a mobile device 12. Consider the example of the in- 
ternal push server 126 within the security firewall 127, 
described below with reference to Fig. 12. Fig. 12 is a 
signal flow diagram illustrating a corporate data push op- 
eration. In keeping with the above illustrative example 
operations, Fig.12 shows an HTTP-based data push op- 
eration. 

[0115] In Fig, 12. an HTTP post request from the in- 
ternal push server 126 is received by the push service 
module 30 and recognized as an HTTP request. The 
push service module 30 loads and Invokes the HTTP 
handler 26 in this example, which then consults the con- 
figuration file 72 or transcoder lookup table to determine 
if the a transcoder is available to transcode the received 
WML content into a device-acceptable format. As de- 
scribed above, an appropriate transcoder may be chosen 
by the IP Proxy system 124 or specified in the request 
from the push server 126. In Fig. 12, the WML->WMLC 
transcoder 74 is loaded and Invoked by the HTTP handler 
26 and the transcoded content is forwarded to the net- 
work server 122 through the dispatcher 22. The network 
server 122 then encrypts the content received from the 
IP Proxy system 124 in its encryption module 122a and 
sends the encrypted content to the mobile device 12. 
[01 1 6] In some Implementations, the protocol conver- 
sion or translation operations associated with the dis- 
patcher 22 may instead be performed by the network 
server 122. In an alternate embodiment, IP Proxy system 
functionality may be incorporated Into a network server 
122 to thereby provide a network server that allows ac- 
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cess to network resources using a mobile device 12. In 
another embodiment, an IP Proxy system 124 may in- 
corporate encryption/decryption and communications 
functions of the network server 122 in order to commu- 
nicate with the wireless network gateway 1 5 (Fig. 1 1 ) and 
thus mobile devices such as 12. 
[0117] The internal push server 1 26 may be associated 
with a computer system or data store preferably config- 
ured for operation on the private network 130, such as a 
file server or other data store accessible through the net- 
work 130. In the example of a corporate network, the 
information source 126 may include confidential or oth- 
erwise sensitive information that an owner of the network 
130 strives to keep private. The security firewall 127 is 
intended to prevent unauthorized access to private net- 
work components including the information source 126. 
In some situations, the very existence of information 
stored at the information source must remain confiden- 
tial. The encryption of content sent to the mobile device 
12 as shown in Fig. 12 prevents an unauthorized party 
from determining the contents of the request without 
breaking the encryption, which as described above is not 
computationally feasible for strong encryption schemes 
such as 30ES. 

[01 1 8] Encryption of pushed content by the encryption 
module 122a in the network server 122 before it is sent 
to the mobile device 1 2 ensures that the content can only 
be viewed by the mobile device 12. Confidential corpo- 
rate Information therefore remains encrypted and thus 
secure until received and decrypted at the mobile device 
1 2, thereby effectively extending the security firewall 1 27 
to the mobile device 12. Information sent by the mobile 
device 1 2 to the network server 1 22 is similarly encrypted 
by the mobile device 12 and remains encrypted until de- 
crypted by the decryption module 122b. For example, an 
HTTP get request may be prepared on the mobile device 
12, and then encrypted and sent from the mobile device 
1 2 to the network server 1 22 in order to request informa- 
tion resident on an information source within the corpo- 
rate network 130. The request remains encrypted until 
received by the network server 122 and decrypted, be- 
hind the security firewall 127, as indicated at 134 in Fig. 
12. The request is therefore virtually as secure as a re- 
quest sent from a computer system on the network 1 30. 
[0119] Once decrypted, the request is passed to the 
HTTP handler 26, which requests the information from 
the appropriate source. Returned information is trans- 
coded if required, passed to the dispatcher 22, encrypted 
by the encryption module 1 22a and returned to the mobile 
device 1 2. Both the request and the information returned 
to the mobile device 1 2 in response thereto are secure. 
[01 20] In known remote data access schemes such as 
WAP, gateway systems which provide for data access 
using mobile devices 1 2 are normally located outside cor- 
porate or private premises, at the location of a service 
provider for example. Any confidential or sensitive infor- 
mation encrypted at the private premises is decrypted at 
the gateway system, outside the corporate firewall, and 



then re-encrypted before being sent to the destination 
mobile device or devices 12. The information is therefore 
in the clear at the gateway system and thus accessible 
by an owner or operator of the gateway system. Further- 
s more, the owner or operator of a private network from 
which the information was sent typically has no control 
over security arrangements at the gateway system, such 
that the information Is vulnerable to attacks on the gate- 
way system. 

10 [0121] The arrangement shown in Figs. 11 and 12 pro- 
vides for secure remote access to private, confidential or 
otherwise sensitive information. Information is encrypted 
from end-to-end between the network server 122 and 
any mobile device 12. Any level of security may be im- 

is piemented at the security firewall 127 to protect confi- 
dential information stored at an internal push server such 
as 128 or other internal information sources, and when 
encrypted by the network server 122, information is not 
decrypted at any intermediate point before being re- 

20 ceived at a mobile device 12. The information is in the 
clear only "inside" the point 134, behind the security fire- 
wall 127, and on the mobile device 12. Security arrange- 
ments such as password or passphrase control are also 
preferably implemented at the mobile device 12 to pre- 

25 vent an unauthorized user from using the mobile device 
or decrypting received encrypted information. For exam- 
ple, computer workstations may be protected by pass- 
word-deactivated system locking and access to a corpo- 
rate network 130 is normally protected by login pass- 

30 words. Similariy, a password may be required to use a 
mobile device 12. while a different passphrase may be 
necessary to decrypt any encrypted information stored 
on the mobile device. A mobile device 12 and information 
stored thereon is thereby just as secure as a network 

35 wori<station and information stored on a network. Such 
techniques as limited password or passphrase entry re- 
tries, mobile device 12 or mobile device memory reset 
after a predetermined number of failed password/pass- 
phrase entries, dynamic and possibly random password/ 

^0 passphrase updates and the like may be used to further 
improve mobile device security. 
[0122] For an extemal information source 132 (Fig. 
1 1 ), a data push operation would be substantially the 
same as shown in Fig. 12, except that the infomiation 

45 source is outside the firewall 127. It should be appreci- 
ated that any information source may be configured to 
provide information in response to a request from an IP 
Proxy system 124, push information to a mobile device 
through an IP Proxy system 124, or possibly to perform 

50 both functions. Any information exchange between the 
mobile device 12 and the network server 122 may be 
encrypted, but Information exchanged with the informa- 
tion source 132 may be unsecure. If the information pro- 
vided by the information source 1 32 is not private orcon- 

55 fidentlal, then unsecure exchange between the IP Proxy 
system 1 24 and the source 1 32 will be sufficient for most 
purposes. However, if the external source 1 32 provides 
private information, then alternate arrangements are 
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preferably provided. 

[0123] One possible measure to improve the security 
of information being requested from an external source 
132 is to secure the communications between the IP 
Proxy system 1 24 and the source 1 32. For example, the s 
IP Proxy system 124 may be adapted to support Secure 
HTTP (HTTPS), Secure Sockets Layer (SSL) or other 
secure communication schemes in order to securely ac- 
cess information at the information source 1 32. Informa- 
tion from the source 132 may thereby be securely trans- 
ferred to the IP Proxy system 124 and is then protected 
by the security firewall 127. Encrypted information may 
be decrypted by the IP Proxy system 124, by the active 
connection handler for example, and transferred to the 
network server 1 22, which then encrypts the information 
for transmission to the mobile device 12. As above, in- 
formation is only in the clear behind the firewall 127. Al- 
ternatively, a secure communication session may be es- 
tablished between the mobile device 12 and source 132 
through the IP Proxy system 124. In the system of Fig. 

11, communications between the mobile device 12 and 
network server 122 would then be double-encrypted. 
[0124] As shown in Fig. 1 1 , the network server 122 is 
also associated with the email system 128. In one em- 
bodiment, the network server 122 provides redirection of 
data items from the email system 128 to mobile device 

12. One such system is described in detail in United 
States Patent 6,219,694, entitled "System And Method 
For Pushing Information From A Host System To A Mo- 
bile Data Communication Device Having A Shared Elec- 
tronic Address", and issued to the assignee of the present 
application on April 17, 2001. The complete disclosure 
of this patent is hereby incorporated into this application 
by reference . 

[01 25] Since the network server 1 22 is also associated 
with the I P Proxy system 124, integrated functionality 
between the email system 128 and the IP Proxy system 
124 may be possible. For example, the IP Proxy system 
1 24 may use encryption functionality of the network serv- 
er 1 22 as well as a transport mechanism via which the 
network server 1 22 communicates with the mobile device 
12. Other functions of the network server 122, such as 
data compression for example, may similarly be exploited 
by an IP Proxy system 124 to improve the efficiency of 
use of wireless communication resources. 
[0126] Similarly, content destined for a mobile device 
1 2 may be addressed to the mobile device using an email 
address in the email system 128 associated with the mo- 
bile device user. In this example, content fooA/arded to 
the mobile device 12 by the IP Proxy system 124 may 
also be stored in the user's mailbox on email system 128 
by the network server 122, as indicated in Fig. 11, to 
thereby provide both a record of IP Proxy system oper- 
ations and a stored copy of any forwarded content. Other 
integrated functions may include but are in no way limited 
to email-based content requests from mobile devices and 
addressing of device-destined information by the IP 
Proxy system 124 using an email address on the email 



system 128. Still further integrated functions may be en- 
abled where a network server 1 22 or the IP Proxy system 
124 is associated with any other services. 
[0127] It will be appreciated that the above description 
relates to exemplary embodiments by way of example 
only. Other variations exist and are within the scope of 
the invention. For example, embodiments of the invention 
have been described primarily in the context of an IP- 
based system. Similar proxy systems for other types of 
communication systems are also contemplated within 
the scope of the invention. Other types of connections, 
connection handlers and transcoders than those de- 
scribed above will also be apparent to those skilled in the 
art. 

[0128] Depending upon the particular implementation 
of a remote data access system and the features to be 
supported, not all of the elements shown in Fig. 2 are 
required. 

[0129] The instant invention is also in no way limited 
to content type indication using MIME types. MIME types 
are useful in conjunction with the instant invention, but 
are not required to practice the invention. Other content 
type indicators may be substituted for MIME type to in- 
dicate the type or format of requested or received content. 
[01 30] Although the transcoders described above con- 
vert between well-known information types or formats, 
custom transcoders could be developed and implement- 
ed for virtually any information format, including for ex- 
ample application program file types and proprietary for- 
mats. As described above, a proxy system in accordance 
with the instant invention is preferably configurable and 
new content transcoders may be added. 
[01 31] It is also possible that information content from 
an infomriation source may include multiple different con- 
tent types, not just a single content type as described 
above. For such multiple-type content, transcoders may 
be selected, for example, to transcode the content into 
a single content type, or into multiple content types ac- 
cepted at a mobile device. Selection of transcoders may 
be controlled according to any of the transcoder selection 
schemes described above. In the case of transcoder se- 
lection by a mobile device or information source, a list of 
transcoders for any or each part of multiple-type infor- 
mation type content may be specified in a connection 
request, a response to a request, or a push request. A 
respective transcoder may be selected and used for each 
part of the information content having a particular content 
type. A push server may instead transcode any or all 
parts of multiple-type information content before such 
content is pushed to a mobile device. 
[01 32] When any part of multiple-type information con- 
tent cannot be transcoded as desired or required, where 
a suitable transcoder is not available for example, only 
other parts of the information content might be transcod- 
ed and sent to a mobile device. Alternatively, a default 
transcoding operation as described above may be used 
to transcode parts of multiple-type content. Non-trans- 
coded parts of multiple-type content, or possibly all of the 
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multiple-type content, could instead be replaced with a 
link orother information that may be used to subsequently 
access the Information content or parts thereof, and sent 
to a mobile device. Information indicating the multiple 
content types and/or required or recommended trans- 
coders could also be sent to the mobile device. The in- 
formation content or parts thereof may then be retrieved 
by the mobile device by submitting a connection request 
or possibly further transcoding instructions or an alter- 
nate transcoder selection to an IP Proxy system. 
[0133] Furthermore, a proxy system may be imple- 
mented in any network, not only in a corporate network 
as shown in Fig. 1 1 . Installation of a proxy system in an 
ISP. ASP, or Virtual Network Operator (VNO) system 
would provide for secure remote access to network In- 
formation and secure transferof information between any 
network users, including transfers between mobile de- 
vices of ISP, ASP or VNO users. 
[0134] It is noted that although the description of the 
invention is made for particular arrangements, the intent 
and concept of the present invention are suitable and 
applicable to other arrangements. 



Claims 

1. A system for pushing information content from an 
information source (20) to a mobile communication 
device (12) over a network (14, 16), comprising: 

a transcoding system (28, 86) comprising a plu- 
rality of transcoders (74, 82, 96. 104), each 
transcoder (74, 82, 96, 104) operable to trans- 
code the information content from a respective 
input content type into a respective output con- 
tent type; and 

a first network device in communication with the 
transcoding system (28, 86), the first network 
device comprising a push module (30. 93), the 
push module (30, 93) being operable to receive 
a connection request from the information 
source (20) comprising an identifier associated 
with said mobile communication device (12), the 
push module (30. 93) further being operable to 
select a corresponding connection handler (24. 
26, 94) based on the received connection re- 
quest, the selected connection handler (24, 26, 
94) being operable to select one or more trans- 
coder (74, 82, 96, 104) from the plurality of trans- 
coders (74, 82, 96, 104) based on said identifier 
associated with said mobile communication de- 
vice (12) to transcode the information content, 

wherein the transcoded information content is trans- 
mitted to the mobile communication device (12). 

2. The system of claim 1 , wherein the first network de- 
vice is further operable to transmit the information 



content transcoded by the one or more selected 
transcoders (74, 82, 96, 104) to the mobile commu- 
nication device (12). 

5 3. The system of claim 1 , wherein the transcoding sys- 
tem (28. 86) is further operable to transmit the infor- 
mation content transcoded by the one or more se- 
lected transcoders (74, 82, 96, 104) to the mobile 
communication device (12). 

10 

4. The system of claim 1 , wherein the connection han- 
dler (24 , 26, 94) is operable to determine one or more 
acceptable content types that the mobile communi- 
cation device (12) is configured to accept. 

IS 

5. The system of claim 4, wherein the connection han- 
dler (24, 26, 94) is operable to search the plurality 
of transcoders (74, 82. 96, 104) for transcoders op- 
erable to transcode the Information content from a 

20 received content type of the information content into 
the one or more acceptable content types. 

6. The system of claim 4, wherein the transcoding sys- 
tem (28, 86) is operable generate and store mapping 

25 data comprising transcoding chains, each transcod- 
ing chain selecting one or more transcoders (74, 82, 
96, 104) to transcode the information content from 
a respective input content type into a respective out- 
put content type. 

30 

7. The system of claim 6, wherein the connection han- 
dler (24, 26, 96) is operable to select a transcoding 
chain to transcode the information content from a 
received content type of the information content into 

35 one of the accepted content types. 

8. The system of claim 4, wherein the transcoding sys- 
tem (28, 86) comprises a configuration file (102) as- 
sociated with the plurality of transcoders (74, 82. 96. 

^0 104), and the connection handler (24, 26. 94) is op- 
erable to search the configuration file (102) to deter- 
mine whether any of the transcoders (74, 82, 96, 
1 04) are operable to transcode the information con- 
tent from a received content type of the information 

^5 content into the one or more acceptable content 
types, and to select the transcoders (74, 82, 96, 1 04) 
where any of the transcoders are operable to trans- 
code the information content from the received con- 
tent type into the one or more acceptable content 

50 types. 

9. The system of claim 8, wherein the connection han- 
dler (24, 26. 94) Is further operable to transmit an 
error message to the information source where none 

55 of the transcoders (74, 82. 96. 1 04) are operable to 
transcode the Information content from the received 
content type into the one or more acceptable content 
types. 
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10. The system of claim 8, wherein the information con- 
tent includes multiple content types, and the connec- 
tion handler (24, 26, 94) is further operable to trans- 
mit an error message to the information source 
where none of the transcoders (74, 82, 96, 1 04] are 5 
operable to transcode one or more of the multiple 
content types into the one or more acceptable con- 
tent types. 

1 1 . The system of claim 8, wherein the connection han- io 
dier (24, 26, 94) is further operable to transmit a list 

of selectable transcoders (74, 82, 96, 104) to the 
information source where none of the transcoders 
are operable to transcode the information content 
from the received content type into the one or more 
acceptable content types. 

12. The system of claim 1 1 , wherein the connection han- 
dler (24, 26, 94) is operable to receive selected trans- 
coder data from the information source and to select 20 
one of the selectable transcoders (74, 82, 96, 104) 
from the list of selectable transcoders based on the 
selected transcoder data. 

1 3. The system of claim 8, wherein the connection han- 25 
dler (24, 26, 94) is further operable to discard the 
information content where none of the transcoders 
(74, 82, 96, 104) are operable to transcode the in- 
formation content from the received content type into 

the one or more acceptable content types. 30 

14. The system of claim 8. wherein the connection han- 
dler (24, 26, 94) is further operable to pass the infor- 
mation content where none of the transcoders (74, 

82, 96, 1 04) are operable to transcode the informa- 35 
tion content from the received content type into the 
one or more acceptable content types. 

15. The system of claim 8, wherein the transcoding sys- 
tem is further operable to transcode the information 40 
content into a content type pushed to the mobile com- 
munication device (12) in response to a previous 
connection request where none of the transcoders 
(74. 82, 96, 104) are operable to transcode the in- 
fonnation content from the received content type into 45 
the one or more acceptable content types. 

16. The system of claim 1, wherein the identifier com- 
prises a network address of the mobile communica- 
tion device (12). so 

17. A method for pushing information to a mobile com- 
munication device (12), comprising the steps of: 

receiving a connection request from an informa- ss 
tion source (20) without first sending a request 
for the information, the connection request com- 
prising an identifier of the mobile communication 



device (12) receiving information content; 
providing a plurality of transcoders (74, 82, 96, 
1 04), each transcoder (74, 82, 96, 1 04) operable 
to transcode information content from a first con- 
tent type into a second content type; 
selecting one of a plurality of connection han- 
dlers (24, 26, 94) based on the received con- 
nection request; 

selecting one or more transcoders (74, 82, 96, 
104) from the plurality of transcoders (74, 82, 
96, 104), the one or more transcoder (74, 82, 
96, 104) being selected by the connection han- 
dler (24, 26, 94) based on said identifier asso- 
ciated with said mobile communication device 
(12); 

transcoding the information content using the 
one or more of the plurality of transcoders (74, 
82, 96, 104) selected to generate transcoded 
infonmation content; and 
sending the transcoded infonmation content to 
the mobile communication device (12). 

18. The method of claim 17, wherein the step of selecting 
one or more transcoders from the plurality of trans- 
coders (74, 82, 96, 104) comprises the steps of: 

determining whether any of the plurality of trans- 
coders (74, 82, 96, 104) are operable to trans- 
code the information content from a received 
content type of the information content into any 
of one or more accepted content types that the 
mobile communication device (1 2) is configured 
to accept; and 

selecting a transcoder operable to transcode the 
information content from the received content 
type into one of the accepted content types 
where any of the plurality of transcoders (74, 82, 
96, 104) are operable to transcode the informa- 
tion content from the received content type into 
any of the one or more accepted content types. 

1 9. The method of claim 1 8, further comprising the steps 
of: 

transmitting a list of selectable transcoders to 
the information source where none of the plu- 
rality of transcoders (74, 82, 96, 104) are oper- 
able to transcode the information content from 
the received content type into any of the one or 
more accepted content types; 
receiving selected transcoder data from the in- 
formation source; and selecting one of the se- 
lectable transcoders from the list of selectable 
transcoders based on the selected transcoder 
data. 

20. The method of claim 17, wherein the information 
source is a web server connected to the Intemet. 
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21. The method of claim 17, furthercomprising the steps 
of: 

receiving a network address specifying the lo- 
cation of a transcoder operable to transcode the 
information content from the received content 
type into one of the accepted content types; 
accessing the location specified by the network 
address; and 
retrieving the transcoder. 

22. The method of claim 17, wherein the step of trans- 
coding the information content using one or more of 
the plurality of transcoders (74, 82. 96, 1 04) selected 
comprises the steps of: 

sending the information content to a transcoding 
system (28, 86); and 

receiving transcoded information content from 
the transcoding system (28, 86). 

23. The method of claim 1 7, wherein the step of sending 
the transcoded information content to the mobile 
communication device (12) comprises the step of 
encrypting the transcoded information content. 

24. The method of claim 1 7, wherein the step of selecting 
one or more transcoders from the plurality of trans- 
coders (74, 82, 96, 104) comprises the steps of: 

generating a list of transcoders according to an 
order of preference; and selecting one or more 
of the transcoders in the list of transcoders 
based on the order of preference. 

25. The method of claim 17, furthercomprising the step 
of mapping the plurality of transcoders (74, 82, 96, 
104) to create a plurality of transcoding chains, each 
transcoding chain associating one or more transcod- 
ers to transcode a respective input content type into 
a respective output content type. 

26. The method of claim 25, wherein the step of selecting 
one or more transcoders from the plurality of trans- 
coders (74, 82, 96, 104) comprises the steps of: 

Identifying transcoding chains having a respec- 
tive Input content type matching a received con- 
tent type of the information content and a re- 
spective output content type matching one of 
one or more accepted content types that the mo- 
bile communication device (12) is configured to 
accept; and 

selecting an identified transcoding chain to 
transcode the information content. 

27. The method of claim 26, further comprising the steps 
of: 



determining a priority status related to the infor- 
mation content; and 

transcoding the information content or passing 
the infomiation content depending on the priority 
s status. 

28. The method of claim 17, wherein the mobile com- 
munication device (12) is configured to accept one 
or more content types selected from the group con- 

10 sisting of Wireless Markup Language (WML), Hyper- 
text Markup Language (HTML), compiled WML 
(WMLC) and Extensible Markup Language (XML). 

29. The method of claim 17, wherein the step of selecting 
IS one or more transcoders from the plurality of trans- 
coders (74, 82, 96, 104) comprises the step of se- 
lecting one or more transcoders from the plurality of 
transcoders (74, 82, 96, 104) based on the address 
of the mobile communication device (12). 

20 

30. The method of claim 17, wherein the step of selecting 
one or more transcoders from the plurality of trans- 
coders (74, 82, 96, 104) comprises the steps of: 

25 determining whether the information content 

has been pre-transcoded into a content type that 
the mobile communication device (1 2) is config- 
ured to accept; and 

transmitting the information content to the mo- 
30 bile communication device (12) without further 

transcoding where the Information content has 
been pre-transcoded. 



35 Patentanspruche 

1. System zum Pushen von Informations-Content von 
einer Informationsquelle (20) zu einem mobilen 
Kommunikations-Gerdt (12) uber ein Netzwerk (14, 
^0 16), umfassend: 

ein Transcoder-System (28, 86), umfassend ei- 
ne Mehrzahl von Transcodem (74, 82, 96. 104), 
wobei jeder Transcoder (74. 82, 96, 104) aus- 
^5 gestaltet ist, den Informations-Content von ei- 

nem jeweiligen Eingangs-Content-Typ in einen 
jeweiligen Ausgangs-Content-Typ zu transco- 
dleren; und 

ein erstes Netzwerk-GerSt in Kommunlkatlon 
50 mit dem Transcoder-System (28, 86), wobei das 

erste Netzwerk-Gerat ein Push-Modul (30, 93) 
umfasst, wobei das Push-Modul (30, 93) fahig 
ist, eine Verblndungsanfrage von der Informati- 
onsquelle (20) zu empfangen, welche ein dem 
55 mobilen Kommunikations-Ger§t (1 2) zugeh6rl- 

ges Identifizierungszeichen umfasst, wobei das 
Push-Modul (30, 93) ferner fahig ist. einen ent- 
sprechenden Connection-Handler (24, 26, 94) 
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basierend auf der empfangenen Verbindungs- 
anfrage auszuwShlen, wobei der ausgewdhlte 
Connection-Handler (24, 26, 94) fahig ist, einen 
Oder mehrere Transcoder (74, 82, 96, 104) von 
der Mehrzahl der Transcoder (74, 82, 96, 104) 
basierend auf dem dem mobilen Kommunikati- 
ons-GerSt (1 2) zugeh6rigen Identlfizierungszei- 
chen (12) auszuwShlen, um den Informations- 
Content zu transcodieren. 

wobei der transcodierte Informations-Content zu 
dem mobilen Kommunikations-GerSt (12) ubertra- 
gen wird. 

2. Das System nach Anspruch 1 , wobei das erste Netz- 
werk-GerSt ferner fahig ist, den Informations-Con- 
tent, welche von dem einen oder den mehreren aus- 
gewShlten Transcodern (84, 82, 96, 104) transco- 
dlert worden ist, zu dem mobilen Kommunikatlons- 
Gerdt (12) zu ubertragen. 

3. Das System nach Anspruch 1 , wobei das Transco- 
der-System (28. 86) ferner fShig ist, den Informati- 
ons-Content, welche von dem einen oder den meh- 
reren ausgewShlten Transcodern (74, 82, 96, 104) 
transcodiert worden ist, zu dem mobilen Kommuni- 
kations-Gerat (12) zu ubertragen. 

4. Das System nach Anspruch 1 , wobei der Connec- 
tion-Handler (24, 26, 94) fahig ist, einen oder meh- 
rere akzeptierte Content-Typen zu bestimmen. wo- 
bei das mobile Kommunikations-Gerat (12) dahin- 
gehend konfiguriert ist, diese akzeptlerten Content- 
Typen zu akzeptleren. 

5. Das System nach Anspruch 4, wobei der Connec- 
tion-Handler (24, 26, 94) fahig ist, die Mehrzahl von 
Transcodern (84, 82 , 96, 104) nach Transcodern zu 
durchzusuchen, die fahig sind, den Infomiations- 
Content von einem empfangenen Content-Typ des 
Informations-Contents in den einen oder die mehre- 
ren akzeptlerten Content-Typen zu transcodieren. 

6. Das System nach Anspruch 6, wobei das Transco- 
der-System (28, 86) f^hig ist, Abbildungs-Daten zu 
generieren und zu speichern, welche Transcoder- 
Ketten enthalten, wobei jede Transcoder-Kette ei- 
nen Oder mehrere Transcoder (84, 82, 96. 104) aus- 
wShlt, die den Informations-Content von eInem je- 
weiligen Eingangs-Content-Typ in einen jeweiligen 
Ausgangs-Content-Typ transcodieren. 

7. Das System nach Anspruch 6, wobei der Connec- 
tion-Handler (24, 26, 96) fShig ist, eine Transcoder- 
Kette auszuwShlen, die den Informations-Content 
von einem empfangenen Content-Typ des Informa- 
tions-Contents in einen derakzeptierten Content-Ty- 
pen transcodiert. 



8. Das System nach Anspruch 4, wobei das Transco- 
der-System (28, 86) eine Konfigurations-Datei (1 02) 
umfasst, welche mit der IVIehrzahl von Transcodern 
(84, 82, 96, 1 04) In Zusammenhang steht, und wobei 

5 der Connection-Handler (24, 26, 94) fShig ist, die 
Konfigurations-Datei (102) zu durchsuchen, um zu 
bestimmen, ob irgendwelche der Transcoder (74, 
82, 96, 104) fahig sind, den Informations-Content 
von einem empfangenen Content-Typ des Informa- 

10 tions-Contents in den einen oder die mehreren ak- 
zeptierten Content-Typen zu transcodieren, und 
Transcoder (74, 82, 96, 104) auszuwelhlen, wobei 
jeder diese Transcoder fahig ist, Informations-Con- 
tent von einem empfangenen Content-Typ in den 

IS einen oder die mehreren akzeptlerten Content-Ty- 
pen zu transcodieren. 

9. Das System nach Anspruch 8, wobei der Connec- 
tion-Handler (24, 26, 94) ferner fahig ist, eine Fehler- 

20 Mitteilung an die Informatlonsquelle zu senden, 
wenn keine der Transcoder fahig sind. den Informa- 
tions-Content von dem empfangenen Content-Typ 
in den einen oder die mehreren akzeptlerten Con- 
tent-Typen zu transcodieren. 

25 

10. Das System nach Anspruch 8, wobei der Informati- 
ons-Content mehrere Content-Typen beinhaltet und 
der Connection-Handler (24 ,26, 94) ferner fahig ist, 
eine Fehler-Mitteilung an die Informatlonsquelle zu 

30 senden, wenn keinederTranscoder (74, 82, 96, 1 04) 
fahig sind, einen oder mehrere der mehreren Con- 
tent-Typen in den einen oder die mehreren akzep- 
tlerten Content-Typen zu transcodieren. 

35 11. Das System nach Anspruch 8, wobei der Connec- 
tion-Handler (24. 26, 94) ferner fahig ist, eine Liste 
von auswahlbaren Transcodern (74, 82, 96, 104) an 
die Informatlonsquelle zu senden, wenn keine der 
Transcoder fahig sind, den Informations-Content 
40 von dem empfangenen Content-Typ in den einen 
Oder die mehreren akzeptlerten Content-Typen zu 
transcodieren. 

12. Das System nach Anspruch 1 1 , wobei der Connec- 
ts tlon-Handler (24, 26, 94) fahig ist, Daten ausgewShl- 

ter Transcoder von der Informatlonsquelle zu emp- 
fangen und einen der auswahlbaren Transcoder (74, 
82, 96, 1 04) aus der Liste der auswShlbaren Trans- 
coder basierend auf den Daten ausgewdhlterTrans- 
50 coder auszuwShlen. 

13. Das System nach Anspruch 8, wobei der Connec- 
tion-Handler (224, 26, 94) ferner fdhig ist, Informati- 
ons-Content zu verwerfen, wenn keine der Transco- 

55 der (74, 82, 96, 104) fahig sind, den Informations- 
Content von dem empfangenen Content-Typ in den 
einen oder die mehreren akzeptlerten Content-Ty- 
pen zu transcodieren. 
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14. Das System nach Anspruch 8, wobei der Connec- 
tion-Handler (24, 26, 94) ferner fahig ist, Infornnati- 
ons-Content passieren zu lassen, wenn keine der 
Transcoder (74, 82, 96, 104) fahig sind. den Infor- 
nfiatlons-Content von dem empfangenen Content- s 
Typ in den einen oder die mehreren akzeptlerten 
Content-Typen zu transcodieren. 

15. Das System nach Anspruch 8, wobei das Transco- 
der-System ferner fahig Ist, den Informations-Con- io 
tent in einen Content-Typ zu transcodieren, welcher 

in Antwort auf eine vorherige Verbindungsanfrage 
auf das mobile Kommunlkatlons-Gerdt (12) gepusht 
wurde. 

IS 

16. Das System nach Anspruch 1 , wobei das Identifizie- 
rungszeichen eine Netzwerk-Adresse des mobilen 
Kommunikations-GerStes (12) beinhaltet. 

17. Ein Verfahren zum Pushen von Information auf ein 20 
mobiles Kommunikations-GerSt (12), welches die 
Schritte umfasst: 

Empfangen einer Verbindungsanfrage von ei- 
ner Informationsquelle (20), ohne dass zu- 2S 
nachst eine Anfrage nach der Information ge- 
sendet wird, wobei die Verbindungsanfrage ein 
Identiflzierungszeichen des mobilen Kommuni- 
kations-Gerdts (12) umfasst, welches Informa- 
tions-Content empfSngt; 30 
Bereitsteilen einer Mehrzahl von Transcodern 
(74, 82, 96, 104), wobei jeder Transcoder (74, 
82, 96, 104) fahig ist, Informations-Content von 
einem ersten Content-Typ in einen zweiten Con- 
tent-Typ zu transcodieren; 35 
Auswahlen eines einer Mehrzahl von Connec- 
tion-Handler basierend auf der empfangenen 
Verbindungsanfrage; 

Auswahlen eines oder mehrerer Transcoder 
(74. 82, 96, 104) aus der Mehrzahl von Trans- 40 
codern (74, 82, 96, 104), wobei der eine oder 
die mehreren Transcoder (74, 82, 96, 104) ba- 
sierend auf dem dem mobilen Kommunikations- 
Gerat (12) zugehdrigen Identiflzierungszeichen 
von dem Connection-Handler (24, 26, 94) aus- 
gewahit werden; 

Transcodieren des Informations-Contents, wo- 
bei der eine oder die mehreren der Mehrzahl 
von Transcoder (74, 82, 96, 104) verwendet 
werden, welche ausgewahit worden sind, um so 
transcodierten Informations-Content zu gene- 
rieren; und 

Senden des transcodierten Informations-Con- 
tents zu dem mobilen Kommunikations-Gerat 
(12). 55 

18. Das Verfahren nach Anspruch 1 7, wobei der Schritt 
des Auswdhlens eines oder mehrerer Transcoder 
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von der Mehrzahl von Transcoder (74, 82, 96. 104) 
die Schritte umfasst: 

Bestimmen, ob irgendwelche der Mehrzahl von 
Transcoder (74, 82, 96, 104) fdhig sind, den In- 
formations-Content von einem empfangenen 
Content-Typ des Informations-Content in ir- 
gendeinen der einen oder der mehreren Con- 
tent-Typen zu transcodieren, wobei das mobile 
Kommunikations-Gerat (1 2) konfiguriert ist, die- 
se zu akzeptieren; und 

Auswahlen eines Transcoders, welcher fahig 
Ist, den Informations-Content von dem empfan- 
genen Content-Typ in einen der akzeptierten 
Content-Typen zu transcodieren, wenn irgend- 
welche der Mehrzahl von Transcodern (74, 82, 
96, 104) fahig sind, den Informations-Content 
von dem empfangenen Content-Typ in irgend- 
einen der einen oder der mehreren akzeptierten 
Content-Typen zu transcodieren. 

19. Das Verfahren nach Anspruch 18, welches ferner 
die Schritte umfasst: 

Senden einer Liste von auswahlbaren Transco- 
dern an die Informationsquelle, wenn keine der 
Mehrzahl von Transcodern (74, 82, 96, 104) fa- 
hig sind, den Informations-Content von dem 
empfangenen Content-Typ in irgendeinen der 
einen oder der mehreren akzeptierten Content- 
Typen zu transcodieren; 
Empfangen von Daten ausgewahlter Transco- 
der von der Infomiationsquelie; und Auswahlen 
eines von den auswahlbaren Transcodern aus 
der Liste der auswahlbaren Transcoder basie- 
rend auf den Daten ausgewahlter Transcoder. 

20. Das Verfahren nach Anspruch 17, wobei die Infor- 
mationsquelle ein Web-Server ist, welcher mit dem 
Internet verbunden ist. 

21. Das Verfahren nach Anspruch 17, welches ferner 
die Schritte umfasst: 

Empfangen einer Netzwerk-Adresse, welche 
den Speicherort eines Transcoders spezifiziert, 
welcher fahig ist, den Informations-Content von 
dem empfangenen Content-Typ in einen der ak- 
zeptierten Content-Typen zu transcodieren; 
Zugreifen auf den Speicherort, der durch die 
Netzwerk-Adresse spezifiziert ist; und 
Abrufen des Transcoders. 

22. Das Verfahren nach Anspruch 17, wobei der Schritt 
des Transcodierens des Informations-Contents un- 
ter Verwendung eines oder mehrerer der Mehrzahl 
von Transcoder (74, 82, 96, 104), welche ausge- 
wahit worden sind, die Schritte umfasst: 
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Senden des Informations-Contents an ein 
Transcoder-System (28, 86); und 
Empfangen transcodierten Informations-Con- 
tents von dem Transcoder-System (28, 86). 

5 

23. Das Verfahren nach Anspruch 1 7, wobel der Schritt 
des Sendens des transcodierten Informations-Con- 
tents zu dem mobllen Kommunlkatlons-Gerats (12) 
den Schritt des Verschlusselns des transcodierten 
Informations-Contents umfasst. 

24. Das Verfahren nach Anspruch 1 7, wobei der Schritt 
des Auswahlens eines oder mehrer Transcoder aus 
der Mehrzahl von Transcodern (74, 82, 96, 104) die 
Schritte umfasst: is 

Generieren einer Liste von Transcodern gemali 
einer Reihenfolge der PrSferenz; und Auswah- 
len eines Oder mehrerer der Transcoder in der 
Liste der Transcoder basierend auf der Reihen- 20 
folge der PrSferenz. 

25. Das Verfahren nach Anspruch 17, welches ferner 
den Schritt des Abbildens der Mehrzahl von Trans- 
coder (74, 82, 96, 104) umfasst, um eine Mehrzahl 25 
von Transcoder-Ketten zu erzeugen, wobei jede 
Transcoder-Kette mit einem oder mehreren Trans- 
codern verknupft ist, um einen jeweiligen Eingangs- 
Content-Typ in einen jeweiligen Ausgangs-Content- 
Typ zu transcodieren. 30 

26. Das Verfahren nach Anspruch 25, wobei der Schritt 
des AuswShlens eines oder mehrerer Transcoder 
aus der Mehrzahl von Transcodern (74, 82, 96, 1 04) 

die Schritte umfasst: 35 

Identifizieren von Transcoder-Ketten, welche ei- 
nen jeweiligen Eingangs-Content-Typ aufwei- 
sen. der zu einem empfangenen Content-Typ 
passt, und welche einen jeweiligen Ausgangs- ^0 
Content-Typ aufweisen, welcher zu einem der 
einen oder der mehreren akzeptablen Content- 
Typen passt, wobei das mobile Kommunikati- 
ons-Gerdt (1 2) dahingehend konfiguriert ist, die- 
se akzeptablen Content-Typen zu akzeptieren. ; 45 
und 

AuswShlen einer identifizierten Transcoder-Ket- 
te, um den Infomfiations-Contentzu transcodie- 
ren. 

so 

27. Das Verfahren nach Anspruch 26. welches femer 

die Schritte umfasst: 

Bestimmen eines Prioritdtstatus, welcher auf 
den Informations-Content bezogen ist; und ss 
Transcodieren des Informations-Contents oder 
Passierenlassen des Informations-Contents in 
Abh£ingigkeit von dem Prioritdtsstatus. 
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28. Das Verfahren nach Anspruch 17, wobei das mobile 
Kommunikations-Gerat (12) konfiguriert ist, einen 
Oder mehrere Content-Typen ausgewahit aus der 
Gruppe umfassend Wireless Markup Language 
(WML), Hypertext Markup Language (HTML), com- 
plied WML (WMLC) und Extensible Markup Langua- 
ge (XML) zuzulassen. 

29. Das Verfahren nach Anspruch 17, wobei der Schritt 
des Auswdhlens eines oder mehrerer Transcoder 
von der Mehrzahl von Transcodern (74, 82, 96, 1 04) 
den Schritt des Auswahlens eines oder mehrerer 
Transcoder von der Mehrzahl von Transcodern (74, 
82, 96, 104) basierend auf der Adresse des mobllen 
Kommunikations-Gerdts (12) umfasst. 

30. Das Verfahren nach Anspruch 1 7, wobei der Schritt 
des Auswahlens eines oder mehrerer Transcoder 
aus der Mehrzahl von Transcodern (74, 82, 96, 104) 
die Schritte umfasst: 

Bestimmen, ob der Informations-Content in ei- 
nen Content-Typ vor-transcodiert worden ist, 
wobei das mobile Kommunikations-Gerat (12) 
dahingehend konfiguriert ist, diesen Content- 
Typen zu akzeptieren; und 
Ubertragen des Informations-Contents an das 
mobile Kommunikations-Gerat (12) ohne weite- 
res Transcodieren, wenn der Informations-Con- 
tent vor-transcodiert worden ist. 



Revendications 

1. Syst^me permettant de distribuer du contenu d'in- 
formations depuis une source d'informations (20) 
vers un dispositif de communication mobile (12) sur 
un rSseau (14, 16), comprenant : 

un syst^me de transcodage (28, 86) compre- 
nant une plurality de transcodeurs (74, 82, 96, 
1 04), cheque transcodeur (74, 82 , 96, 1 04) etant 
operable pour transcoder le contenu d'informa- 
tions d'un type de contenu d'entr^e respectif en 
un type de contenu de sortie respectif ; et 
un premier dispositif r6seau en communication 
avec le syst^me de transcodage (28, 86), le pre- 
mier dispositif rSseau comprenant un module de 
distribution (30, 93), le module de distribution 
(30, 93) 6tant op6rable pour recevoir une requi- 
te de connexion d partir de la source d'informa- 
tions (20) comprenant un identifiant associ6 
audit dispositif de communication mobile (12), 
le module de distribution (30. 93) 6tant en outre 
operable pour sdlectionner un gestionnaire de 
connexion (24, 26, 94) correspondant d'apr^s 
la requete de connexion regue, le gestionnaire 
de connexion (24, 26, 94) s^lectionnd 6tant op6- 
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rable pour s6(ectionner un ou plusieurs transco- 
deurs (74, 82, 96, 104) ^ partir de la plurality de 
transcodeurs (74, 82, 96, 104) sur la base dudit 
identifiant associ^ audit dispositif de communi- 
cation mobile (1 2) afin de transcoder le contenu s 
d'informations. 

dans lequel le contenu d'informations transcod6 est 
transmis au dispositif de communication mobile (1 2). 

10 

2. Syst6me selon la revendlcation 1 , dans lequel le pre- 
mier dispositif r6seau est en outre op6rable pour 
transmettre le contenu d'informations transcod§ par 
les un ou plusieurs transcodeurs (74, 82, 96, 104) 
s^lectlonn^s au dispositif de communication mobile is 
(12). 

3. Syst^me selon la revendication 1 , dans lequel le sys- 
tSme de transcodage (28, 86) est en outre operable 
pour transmettre le contenu d'informations transco- 20 
d6 par les un ou plusieurs transcodeurs (74, 82, 96, 
104) s6lectionn6s au dispositif de communication 
mobile (12). 

4. SystSme selon la revendication 1 , dans lequel le ges- 25 
tionnaire de connexion (24, 26, 94) est operable pour 
determiner un ou plusieurs types de contenu accep- 
tabtes que le dispositif de communication mobile (12) 

est configure pour accepter. 

30 

5. Syst6me selon la revendication 4, dans lequel le ges- 
tionnaire de connexion (24, 26, 94) est operable pour 
rechercher pamil la plurality de transcodeurs (74, 
82, 96. 1 04) des transcodeurs op^rables pour trans- 
coder le contenu d'infomiations d'un type de contenu 35 
regu du contenu d'informations en les un ou plu- 
sieurs types de contenu acceptables. 

6. Systeme selon la revendication 4, dans lequel le sys- 
t6me de transcodage (28, 86) est operable pour g6- ^0 
n6rer et stocker des donn6es de correspondance 
comprenant des chaines de transcodage, chaque 
chaTne de transcodage s^lectlonnant un ou plu- 
sieurs transcodeurs (74, 82, 96, 104) afin de trans- 
coder le contenu d'infomfiations d'un type de contenu 
d'entr^e respectif en un type de contenu de sortie 
respectif. 

7. Systeme selon la revendication 6, dans lequel le ges- 
tionnaire de connexion (24,26, 96) est operable pour so 
s6lectionner une chaTne de transcodage afin de 
transcoder le contenu d'informations d'un type de 
contenu regu du contenu d'informations en un des 
types de contenu accept^s. 

55 

8. Systdme selon la revendication 4, dans lequel le sys- 
t^me de transcodage (28, 86) comprend un fichier 
de configuration (1 02) associd d la plurality de trans- 



codeurs (74, 82, 96, 104), et le gestionnaire de con- 
nexion (24, 26, 94) est operable pour rechercher le 
fichier de configuration (102) afin de determiner si 
I'un quelconque des transcodeurs (74, 82, 96, 104) 
est operable pour transcoder le contenu d'informa- 
tions d'un type de contenu regu du contenu d'infor- 
mations en les un ou plusieurs types de contenu ac- 
ceptables, et de seiectionner les transcodeurs (74, 
82. 96. 104) lorsque I'un quelconque des transco- 
deurs est operable pour transcoder le contenu d'in- 
formations du type de contenu regu en les un ou 
plusieurs types de contenu acceptables. 

9. Systeme selon la revendication 8, dans lequel le ges- 
tionnaire de connexion (24, 26, 94) est en outre ope- 
rable pour transmettre un message d'erreur e la 
source d'informations lorsque aucun des transco- 
deurs (74. 82, 96, 104) n'est operable pour transco- 
der le contenu d'informations du type de contenu 
regu en les un ou plusieurs types de contenu accep- 
tables. 

1 0. Systeme selon la revendication 8, dans lequel le con- 
tenu d'informations inclut plusieurs types de conte- 
nu. et le gestionnaire de connexion (24, 26, 94) est 
en outre operable pour transmettre un message d'er- 
reur e la source d'informations lorsque aucun des 
transcodeurs (74, 82, 96, 104) n'est operable pour 
transcoder un ou plusieurs des types de contenu 
multiples en les un ou plusieurs types de contenu 
acceptables. 

1 1 . Systeme selon la revendication 8, dans lequel le ges- 
tionnaire de connexion (24, 26, 94) est en outre ope- 
rable pour transmettre une liste de transcodeurs (74, 
82, 96, 104) seiectionnables e la source d'informa- 
tions lorsque aucun des transcodeurs n'est operable 
pour transcoder le contenu d'informations du type 
de contenu regu en les un ou plusieurs types de con- 
tenu acceptables. 

12. Systeme selon la revendication 11, dans lequel le 
gestionnaire de connexion (24, 26, 94) est operable 
pour recevoir des donnees de transcodeurs seiec- 
tlonnes e partir de la source d'informations et pour 
seiectionner un des transcodeurs (74, 82, 96, 104) 
seiectionnables e partir de la liste de transcodeurs 
seiectionnables d'apres les donnees de transco- 
deurs seiectionnes. 

13. Systeme selon la revendication 8, dans lequel le ges- 
tionnaire de connexion (24. 26, 94) est en outre ope- 
rable pour rejeter le contenu d'informations lorsque 
aucun des transcodeurs (74, 82, 96, 1 04) n'est ope- 
rable pour transcoder le contenu d'informations du 
type de contenu regu en les un ou plusieurs types 
de contenu acceptables. 
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14. Syst6me selon la revendication 8, dans lequel le ges- 
tlonnaire de connexion (24, 26, 94) est en outre ope- 
rable pour transmettre le contenu d 'informations 
lorsque aucun des transcodeurs (74. 82. 96, 104) 
n'est op6rable pour transcoder le contenu d'informa- 
tlons du type de contenu regu en les un ou plusieurs 
types de contenu acceptables. 

1 5. Syst§me selon la revendication 8. dans lequel le sys- 
t^me de transcodage est en outre operable pour 
transcoder le contenu d'informations en un type de 
contenu distribu^ au dispositif de communication 
mobile (12) en rSponse d une requete de connexion 
pr^c^dente lorsque aucun des transcodeurs (74, 82. 
96, 104) n'est operable pour transcoder le contenu 
d'informations du type de contenu regu en les un ou 
plusieurs types de contenu acceptables. 

16. Syst^me selon la revendication 1 , dans lequel I'iden- 
tifiant comprend une adresse r^seau du dispositif de 
communication mobile (12). 

17. Proc6d6 permettant de distribuer des informations 
vers un dispositif de communication mobile (12). 
comprenant les 6tapes suivantes : 

recevoir une requite de connexion ^ partir d'une 
source d'informations (20) sans envoyer pr6a- 
lablement une requ§te d'informations, la reque- 
te de connexion comprenant un identifiant du 
dispositif de communication mobile (12) rece- 
vant un contenu d'informations ; 
fournir une plurality de transcodeurs (74, 82, 96, 
1 04), chaque transcodeur (74, 82, 96, 1 04) 6tant 
operable pour transcoder un contenu d'informa- 
tions d'un premier type de contenu en un deuxi6- 
me type de contenu ; 

s6iectionner un parmi une plurality de gestlon- 
naires de connexion (24, 26. 94) d'apr^s la re- 
qu§te de connexion regue ; 
s6lectionner un ou plusieurs transcodeurs (74, 
82, 96, 104) ^ partir de la plurality de transco- 
deurs (74, 82, 96, 1 04), les un ou plusieurs trans- 
codeurs (74, 82, 96, 1 04) 6tant s6lectlonn6s par 
ie gestionnaire de connexion (24. 26, 94) 
d'apr^s ledit identifiant associ§ audit dispositif 
de communication mobile (12) ; 
transcoder le contenu d'informations en utillsant 
les un ou plusieurs de la plurality de transco- 
deurs (74, 82, 96, 104) s6lectlonn6s pour g6n6- 
rer le contenu d'informations transcode ; et 
envoyer le contenu d'informations transcod6 au 
dispositif de communication mobile (12). 

18. Proc^d^ selon la revendication 1 7, dans lequel I'^ta- 
pe de selection d'un ou plusieurs transcodeurs a par- 
tir de la plurality de transcodeurs (74, 82, 96, 104) 
comprend les stapes suivantes : 



determiner si I'un quelconque de la plurality de 
transcodeurs (74, 82, 96, 1 04) est operable pour 
transcoder le contenu d'informations d'un type 
de contenu regu du contenu d'informations en 

5 Tun quelconque d'un ou plusieurs types de con- 

tenu acceptes que le dispositif de communica- 
tion mobile (12) est configure pour accepter ; et 
s6lectlonner un transcodeur operable pour 
transcoder le contenu d'informations du type de 

10 contenu regu en un des types de contenu ac- 

ceptes lorsque I'un quelconque de la pluralite 
de transcodeurs (74, 82, 96, 1 04) est operable 
pour transcoder le contenu d'informations du ty- 
pe de contenu regu en I'un quelconque des un 

IS ou plusieurs types de contenu acceptes. 

19. Precede selon la revendication 18, comprenant en 
outre les etapes suivantes : 

20 transmettre une llste de transcodeurs seiection- 

nables a la source d'informations lorsque aucun 
de la pluralite de transcodeurs (74. 82, 96, 104) 
n'est operable pour transcoder le contenu d'in- 
formations du type de contenu regu en I'un quel- 
25 conque des un ou plusieurs types de contenu 

acceptes ; 

recevoir des donnees de transcodeurs seiec- 
tionnes d partir de la source d'informations ; et 
setectlonner un des transcodeurs seiectlonna- 
30 bles a partir de la liste de transcodeurs seiec- 

tionnables d'apres les donnees de transcodeurs 
seiectionnes. 

20. Precede selon la revendication 17, dans lequel la 
35 source dinformations est un serveur Web connecte 

d Internet. 

21. Precede selon la revendication 17, comprenant en 
outre les etapes suivantes : 

40 

recevoir une adresse reseau specifiant I'empla- 
cement d'un transcodeur operable pour trans- 
coder le contenu d'informations du type de con- 
tenu regu en un des types de contenu acceptes ; 
<s acceder d Templacement specifie par Tadresse 

reseau ; et 

recuperer te transcodeur. 

22. Precede selon la revendication 1 7. dans lequel reta- 
ke pe de transcodage du contenu d'informations en uti- 

lisant un ou plusieurs de la pluralite de transcodeurs 
(74. 82. 96. 104) seiectionnes comprend les etapes 
suivantes : 

55 envoyer le contenu d'informations ^ un systeme 

de transcodage (28, 86); et 
recevoir le contenu d'informations transcode a 
partir du systeme de transcodage (28. 86). 
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23. Proc§d6 selon la revendication 1 7, dans lequel I'^ta- 
pe d'envoi du contenu d'informations transcode au 
dispositif de communication mobile (12) comprend 
r^tape de chiffrage du contenu d'informations trans- 
cod6. 

24. Proc6d6 selon la revendication 1 7, dans lequel l'6ta- 
pe de selection d'un ou plusieurs transcodeurs ci par- 
tir de la plurality de transcodeurs (74, 82, 96, 104) 
comprend les stapes suivantes : 

g6n6rer une liste de transcodeurs selon un ordre 
de pr^f^rence ; et selection ner un ou plusieurs 
des transcodeurs dans la liste de transcodeurs 
selon I'ordre de prdf^rence. 

25. Proc6d6 selon la revendication 17, comprenant en 
outre les stapes de mappage de la plurality de trans- 
codeurs (74, 82, 96, 1 04) pour cr6er une plurality de 
chaTnes de transcodage, chaque chaine de transco- 
dage associant un ou plusieurs transcodeurs afin de 
transcoder un type de contenu d'entr6e respectif en 
un type de contenu de sortie respectif. 

26. Proc^d^ selon la revendication 25, dans lequel I'^ta- 
pe de selection d'un ou plusieurs transcodeurs a par- 
tir de la plurality de transcodeurs (74, 82, 96. 104) 
comprend les stapes suivantes : 

identifier des chaTnes de transcodage ayant un 
type de contenu d'entr6e respectif correspon- 
dant d un type de contenu regu du contenu d'in- 
fomiations et un type de contenu de sortie res- 
pectif correspondant d I'un quelconque d'un ou 
plusieurs types de contenu accept^s que le dis- 
positif de communication mobile (12) est confi- 
gure pour accepter ; et 

s6lectionner une chaine de transcodage identi- 
fi6e pour transcoder le contenu d'informations. 

27. Proc6d6 selon la revendication 26, comprenant en 
outre les stapes suivantes : 

determiner un etat de priorite relatif au contenu 
d'informations ; et 

transcoder le contenu d'informations ou trans- 
mettre le contenu d'informations en fonction de 
retat de priority. 

28. Proc6de selon la revendication 17, dans lequel le 
dispositif de communication mobile (1 2) est configu- 
re pour accepter un ou plusieurs types de contenu 
seiectionn6s d partir du groupe constitu6 par WML 
(Langage de balisage sans fil), HTML (Langage de 
balisage hypertexte). WMLC (WML compile) etXML 
(Langage de balisage extensible). 

29. Precede selon la revendication 1 7, dans lequel reta- 



pe de selection d'un ou plusieurs transcodeurs ci par- 
tir de la pluralite de transcodeurs (74, 82, 96, 104) 
comprend retape consistant ^ s6lectionner un ou 
plusieurs transcodeurs ^ partir de la pluralite de 
5 transcodeurs (74, 82, 96, 1 04) d'apres I'adresse du 
dispositif de communication mobile (12). 

30. Procede selon la revendication 1 7, dans lequel reta- 
pe de selection d'un ou plusieurs transcodeurs e par- 
10 tir de la pluralite de transcodeurs (74, 82, 96. 104) 
comprend les etapes suivantes : 

determiner si le contenu d'informations a ete 
pre-transcode en un type de contenu que le dis- 
positif de communication mobile (12) est confi- 
gure pour accepter ; et 

transmettre le contenu d'informations au dispo- 
sitif de communication mobile (12) sans opera- 
tion de transcodage suppiementaire lorsque le 
contenu d'informations a ete pre-transcode. 
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